> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Eski Public API

> API kirish kalitini bearer tokenga almashtiradigan mavjud /api/v1 integratsiyalarini qo‘llab-quvvatlash.

Ushbu qo‘llanma API kirish kalitini bearer tokenga almashtiradigan mavjud `/api/v1` integratsiyalarini o‘z ichiga oladi. Ularning hisob ma’lumotlari va so‘rov formati `/v1` Public API’dan farq qiladi.

Yangi integratsiya uchun [API quickstart](/uz/developers/v1/quickstart) va [Authentication](/uz/developers/v1/authentication) bo‘limlaridan boshlang. Yangi `/v1` API xizmat hisobi API kalitlaridan yoki OAuth kirish tokenlaridan foydalanadi.

## Boshlashdan oldin

Sizga quyidagilar kerak bo‘ladi:

* API kirish kalitlarini boshqarishga ruxsat beruvchi Living Security’dagi kirish huquqi
* **Settings → Access Keys** bo‘limida yaratilgan API kirish kaliti
* Hisob ma’lumoti yaratilganda ko‘rsatiladigan bir martalik kirish kaliti siri
* Living Security tomonidan Public API hisob ma’lumotlaringiz bilan birga taqdim etilgan API issuer ID
* Integratsiya qilinayotgan tashkilot uchun mintaqaviy asosiy URL
* Server tomonidagi ishga tushirish muhiti va sirlar menejeri

Kirish kaliti sirlarini brauzer kodiga, mobil ilovalarga, manba kodini boshqarish tizimiga, mijoz tomonidagi muhit o‘zgaruvchilariga, tiketlarga yoki umumiy jurnallarga joylashtirmang.

<Note>
  Access Keys oynasi bir martalik sirni ko‘rsatadi, lekin API issuer ID’ni ko‘rsatmaydi. Agar Living Security issuer ID’ni Public API hisob ma’lumotlaringiz bilan birga taqdim etmagan bo‘lsa, uni [Living Security
  Support](mailto:support@livingsecurity.com) xizmatidan so‘rang. Issuer ID kirish kaliti ID’si yoki tashkilot ID’si emas.
</Note>

## Mintaqaviy xostlar

Eski shartnoma quyidagi mintaqaviy `/api/v1` production xostlaridan foydalanadi:

| Mintaqa | Asosiy URL |
| - | - |
| US | `https://api.us-east-1.livingsecurity.ai/api/v1` |
| EU | `https://api.eu-west-1.livingsecurity.ai/api/v1` |

Living Security tashkilotiga biriktirilgan mintaqadan foydalaning. Avtorizatsiya yoki mavjudlik xatosini chetlab o‘tish uchun mintaqani almashtirmang.

## Eski resurslar

| Resurs | Qo‘llab-quvvatlanadigan operatsiyalar |
| - | - |
| **People** | Tashkilot xodimlarini qidirish va shaxsning a’zoligini olish |
| **API access keys** | API kirish kalitlarini yaratish, ro‘yxatini olish, almashtirish va bekor qilish |

To‘liq operatsiyalar, parametrlar, so‘rovlar, javoblar va sxemalar ro‘yxati uchun **Developers → Public API Reference** bo‘limidan foydalaning. Agar operatsiya u yerda bo‘lmasa, u hozirda Public API tarkibiga kirmaydi.

## Authentication

Public API’ga kirish ikki bosqichdan iborat:

1. Maxfiy kirish kaliti va API issuer ID’ni qisqa muddatli bearer token va tashkilot ID’siga almashtiring.
2. Har bir API so‘rovi bilan bearer token va tashkilot ID’sini yuboring.

Talab qilinadigan so‘rov sarlavhalari:

```http theme={null}
Authorization: Bearer <access-token>
x-organization-id: <organization-id>
```

Tashkilot sarlavhasi kirish kalitini almashtirish natijasida qaytarilgan tashkilotga mos bo‘lishi kerak. Kalit ixtiyoriy tashkilot ID’siga kirishga ruxsat bermaydi.

### TypeScript SDK

Joriy asosiy versiyani o‘rnating:

```bash theme={null}
npm install @livingsecurity/sdk@^1
```

So‘ng kalitni almashtiring va SDK’ni sozlang:

```typescript theme={null}
import { configure, exchangeAccessKey } from "@livingsecurity/sdk";

const accessKeySecret = process.env.LS_API_ACCESS_KEY_SECRET;
const apiIssuerId = process.env.LS_API_ISSUER_ID;

if (!accessKeySecret || !apiIssuerId) {
  throw new Error("LS_API_ACCESS_KEY_SECRET and LS_API_ISSUER_ID are required");
}

const { accessToken, organizationId } = await exchangeAccessKey(
  accessKeySecret,
  apiIssuerId,
);

configure({
  baseUrl: "https://api.us-east-1.livingsecurity.ai/api/v1",
  accessToken,
  organizationId,
});
```

EU tashkiloti uchun EU asosiy URL’idan foydalaning. SDK orqali almashtirish server tomonidagi Node.js muhitlari uchun mo‘ljallangan.

### To‘g‘ridan-to‘g‘ri REST so‘rovi

Agar almashtirishni SDK’dan tashqarida amalga oshirsangiz, har bir so‘rovda uning bearer tokeni va tashkilot ID’sini yuboring:

```bash theme={null}
curl --request GET \
  "https://api.us-east-1.livingsecurity.ai/api/v1/people/search?limit=1" \
  --header "Authorization: Bearer $LIVING_SECURITY_BEARER_TOKEN" \
  --header "x-organization-id: $LIVING_SECURITY_ORG_ID" \
  --header "Accept: application/json"
```

Bearer tokenlar qisqa muddatli. Yangi token olish uchun bearer tokenni doimiy hisob ma’lumoti sifatida saqlab qo‘ymasdan, kirish kalitini qayta almashtiring.

## Kirish kalitining hayot aylanishi

* Kalitlarga ularga egalik qiluvchi integratsiya yoki avtomatlashtirish nomini bering.
* Kirish kaliti shakli taklif qiladigan eng kam imtiyozli scope’larni tanlang.
* Bir martalik sirni darhol saqlab qo‘ying; u yaratilgandan yoki almashtirilgandan keyin qayta olinmaydi.
* Kalitni **Settings → Access Keys** orqali almashtiring va eski hisob ma’lumotini bekor qilishdan oldin yangisini joriy qiling.
* Endi foydalanilmaydigan yoki siri oshkor bo‘lishi mumkin bo‘lgan kalitlarni bekor qiling.
* Tashkilotingizda mavjud bo‘lsa, inson ishtirok etmaydigan integratsiyalar uchun xizmat hisobi kalitlaridan foydalaning.

## Pagination

People qidiruvi `limit`, `cursor`, `offset` va `includeTotal` parametrlarini qo‘llab-quvvatlaydi. Ketma-ket o‘tish uchun oldingi javobda qaytarilgan kursordan foydalanish afzalroq.

* `limit` standart qiymati 50 va 1–100 oralig‘ini qabul qiladi.
* `cursor` oldingi javobdan davom ettiradi.
* `offset` belgilangan sondagi yozuvlarni o‘tkazib yuboradi va standart qiymati 0.
* `includeTotal=true` filtrlangan aniq sonni so‘raydi; son kerak bo‘lmasa, uni qoldiring.

Endpoint qaytargan `pagination` obyektini o‘qing. Keyingi sahifani olingan qatorlar soniga qarab hisoblamang yoki alohida sahifalangan so‘rovlarni birlashtirib, qisman natijalarni o‘zingiz saralamang.

## Xatolar

Hujjatlashtirilgan JSON xatolari umumiy ko‘rinishda quyidagicha bo‘ladi:

```json theme={null}
{
  "statusCode": 400,
  "message": "Validation failed",
  "error": "Bad Request"
}
```

`message` satr yoki validatsiya xabarlari massivi bo‘lishi mumkin.

| Status | Ma’nosi | Javob |
| - | - | - |
| `400` | Parametrlar yoki so‘rov tanasi yaroqsiz | Ko‘rsatilgan validatsiya xatolarini tuzating |
| `401` | Bearer token yo‘q, yaroqsiz yoki muddati tugagan | Kirish kalitini qayta almashtiring va bir marta qayta urinib ko‘ring |
| `403` | Hisob ma’lumotida ruxsat yoki tashkilotga kirish huquqi yo‘q | Kalit scope’lari va tashkilot kontekstini tekshiring |
| `404` | Resurs avtorizatsiyalangan tashkilotda mavjud emas | Resurs ID’si va tashkilotni tekshiring |
| `408` | So‘rov vaqti tugadi | Cheklangan eksponensial backoff bilan qayta urinib ko‘ring |
| `429` | So‘rovlar chegarasiga yetildi | Agar `Retry-After` mavjud bo‘lsa, kamida shuncha kuting |
| `5xx` | Xizmatda vaqtinchalik nosozlik | Xavfsiz o‘qish so‘rovlarini cheklangan eksponensial backoff bilan qayta urinib ko‘ring |

Tanlab tayyorlangan shartnoma hozircha yagona umumiy raqamli so‘rovlar chegarasini e’lon qilmaydi va har bir operatsiya uchun javobda request-ID sarlavhasi bo‘lishiga kafolat bermaydi. Qo‘llab-quvvatlash xizmatiga murojaat qilganda UTC vaqtini, metodni, yo‘lni, statusni va tozalangan javob tanasini ilova qiling.

Operatsiya idempotentligi aniq hujjatlashtirilmagan bo‘lsa, create, rotate, revoke yoki delete operatsiyalarini avtomatik qayta urinmang. Noaniq tarmoq nosozligidan keyin resursning joriy holatini tekshiring.

## Moslik va eskirish

V1 odatda qo‘shimchalar orqali rivojlanadi. Mijozlar javobdagi noma’lum maydonlarni e’tiborsiz qoldirishi kerak. Buzuvchi o‘zgarish hujjatlashtirilgan migratsiya yo‘lini talab qiladi; eskirgan operatsiyalar migratsiya davrida sababi, mavjud bo‘lsa almashtiruvchi operatsiyasi va to‘xtatish sanasi bilan birga ma’lumotnomada qoladi.

SDK’ni mos keladigan asosiy versiyaga bog‘lab qo‘ying va yangilashdan oldin uning reliz qaydlarini ko‘rib chiqing. Sxemaning asosiy manbai sifatida birinchi tomon ilova mijozlarini emas, avtomatik yaratilgan Public API Reference’ni hisoblang.

## Public API, MCP va veb-ilova

| Interfeys | Nima uchun ishlatiladi | Moslik modeli |
| - | - | - |
| **Public API** | Mijoz tizimlari, hamkorlar va tashqi avtomatlashtirish | Barqaror, versiyalangan resurslar |
| **MCP** | Ruxsatlarga asoslangan sun’iy intellekt vositalari bilan o‘zaro ta’sir | Vosita shartnomalari va ixcham tuzilmali natijalar |
| **Web application** | Living Security mahsulotidagi inson ishtirokidagi ish jarayonlari | Interfeys bilan birga o‘zgarishi mumkin bo‘lgan ilovaga tegishli shartnomalar |

Sun’iy intellekt vositasini Living Security’ga ulash uchun [MCP Integration](/uz/integrations/mcp) bo‘limiga qarang.

## Yordam olish

Quyidagi ma’lumotlar bilan [Living Security Support](mailto:support@livingsecurity.com) xizmatiga murojaat qiling:

* Tashkilot va mintaqa
* Agar foydalanilgan bo‘lsa, SDK nomi va versiyasi
* UTC vaqt belgisi, metod va yo‘l
* HTTP status va tozalangan xato tanasi

Hech qachon kirish kaliti sirlarini, bearer tokenlarni yoki mijozning shaxsiy ma’lumotlarini kiritmang.

## Related

<CardGroup cols={2}>
  <Card title="API Access Keys" icon="key" href="/uz/integrations/api-keys">
    API hisob ma’lumotlarini yarating, almashtiring va bekor qiling.
  </Card>

  <Card title="MCP Integration" icon="robot" href="/uz/integrations/mcp">
    Qo‘llab-quvvatlanadigan sun’iy intellekt vositalarini Model Context Protocol orqali ulang.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.