API ātrā sākšana

Izveidojiet pakalpojuma kontu un API atslēgu sadaļā Developer Hub, pēc tam veiciet pirmo pieprasījumu. Šajā ātrās sākšanas rokasgrāmatā tiek izmantota autentifikācija ar API atslēgu; OAuth klients nav nepieciešams. Ja jūsu integrācijai ir nepieciešami īslaicīgi OAuth piekļuves žetoni, skatiet sadaļu Autentifikācija.

Priekšnosacījumi

Administratora piekļuve Living Security Dashboard.
Sadaļa Developer Hub ir redzama izvēlnē Settings → Integrations & Developers → Developer Hub.

Akreditācijas datu izveide

Izveidojiet pakalpojuma kontu

Sadaļā Developer Hub atveriet cilni Service accounts un izveidojiet kontu. Piešķiriet tam aprakstošu nosaukumu (piemēram, reporting-pipeline) un piešķiriet atļaujas, kuras drīkst izmantot tā atslēgas — šai rokasgrāmatai pietiek ar organization:read.Konta atļaujas ir augšējā robeža katrai zem tā izveidotajai atslēgai: atslēga nekad nevar darīt vairāk, nekā atļauj tās pakalpojuma konts.

Izveidojiet API atslēgu

Atveriet pakalpojuma konta detalizētās informācijas lapu un izveidojiet atslēgu. Izvēlieties atļaujas, kas nepieciešamas tieši šai atslēgai (konta atļauju apakškopa), un derīguma termiņu — 30, 90 vai 365 dienas vai pielāgotu periodu. Derīguma termiņš ir obligāts.Atslēgas noslēpums sākas ar lsk_live_ un tiek parādīts tikai vienu reizi. Nekavējoties nokopējiet to noslēpumu pārvaldniekā; vēlāk to nevar atgūt.

Nekad neiekļaujiet API atslēgu noslēpumus versiju kontrolē un neiegulstiet tos klienta puses kodā. Jebkurš, kam ir noslēpums, var rīkoties ar atslēgas atļaujām.

Izvēlieties reģionu

Izsauciet reģionālo /v1 resursdatoru, kas atbilst organizācijas datu atrašanās vietai. Atslēgas tiek autentificētas tikai šajā resursdatorā.

Reģions	Pamata URL
US	`https://api.us-east-1.livingsecurity.ai/v1`
EU	`https://api.eu-west-1.livingsecurity.ai/v1`

Ja neesat pārliecināti, kuru resursdatoru izmantot, skatiet sadaļu Reģioni. Derīga atslēga, kas nosūtīta uz otru reģionu, neizdodas ar unauthorized. Izmantojiet reģiona nolaižamo izvēlni zemāk esošajā piemērā, lai pārslēgtu resursdatoru.

Veiciet pirmo pieprasījumu

Ielādējiet LIVING_SECURITY_API_KEY no sava noslēpumu pārvaldnieka pieprasījumu veicošā procesa vidē. Tālāk sniegtie piemēri to nolasa, neiegulstot noslēpumu pirmkodā. Python gadījumā vispirms instalējiet requests.Izsauciet API, norādot noslēpumu HTTP Basic autentifikācijas paroles vai lietotājvārda laukā — der abi varianti, tāpēc klienti, kuriem jābūt aizpildītiem abiem laukiem (piemēram, Power BI Web savienotājs), otrā laukā var ievietot vietturi, piemēram, apikey.

curl --fail-with-body --connect-timeout 5 --max-time 30 \
  https://api.eu-west-1.livingsecurity.ai/v1/organization \
  -u "apikey:${LIVING_SECURITY_API_KEY:?Set LIVING_SECURITY_API_KEY}" \
  -H "Living-Security-Version: 2026-07-01"

curl --fail-with-body --connect-timeout 5 --max-time 30 \
  https://api.eu-west-1.livingsecurity.ai/v1/organization \
  -u "${LIVING_SECURITY_API_KEY:?Set LIVING_SECURITY_API_KEY}:" \
  -H "Living-Security-Version: 2026-07-01"

import os
import requests

BASE = "https://api.eu-west-1.livingsecurity.ai/v1"

response = requests.get(
    f"{BASE}/organization",
    auth=("apikey", os.environ["LIVING_SECURITY_API_KEY"]),
    headers={"Living-Security-Version": "2026-07-01"},
    timeout=(5, 30),
    allow_redirects=False,
)
response.raise_for_status()
if response.status_code != 200:
    raise RuntimeError("Unexpected response; check your regional API URL")
print(response.json())

Veiksmīga atbilde atgriež jūsu organizāciju:

Response

{
  "id": "1e2f3a4b-5c6d-4e7f-8a9b-0c1d2e3f4a5b",
  "object": "organization",
  "name": "Example Corp",
  "region": "eu",
  "plan": "enterprise",
  "subscription_status": "active",
  "created_at": "2024-03-12T18:04:11.000Z"
}

Ja saņemat šo atbildi, jūsu akreditācijas dati darbojas. Pieprasījums arī parādās Developer Hub cilnē Request logs pēc īsa brīža.

Darbojas arī Bearer autentifikācija ar to pašu noslēpumu (Authorization: Bearer lsk_live_...). Basic autentifikācija ir paredzēta, lai rīki, kas atbalsta tikai lietotājvārdu/paroli, piemēram, Power BI Web savienotājs, varētu izveidot savienojumu.

Kā darbojas autentifikācija

Akreditācijas dati nosaka organizāciju. /v1 pieprasījumi nesatur nomnieka atlasītāju: nav ne organizācijas ceļa segmenta, ne organizācijas galvenes. Galvenes x-organization-id nosūtīšana tiek noraidīta ar invalid_request. Resursdatoram joprojām jāatbilst šīs organizācijas reģionam. Skatiet Reģioni.
Atļaujas tiek pārbaudītas katrai darbībai. Katrai /v1 darbībai nepieciešama nosaukta atļauja (piemēram, GET /v1/organization nepieciešama organization:read). Atslēga, kurai trūkst atļaujas, saņem 403 ar kodu insufficient_permission.
Atslēgām beidzas derīguma termiņš, un tās var rotēt bez dīkstāves. Skatiet API atslēgas, lai uzzinātu par rotāciju ar pārklāšanās logu.

Kļūdu atbilžu lasīšana

Katra /v1 kļūda ir application/problem+json (RFC 9457) ar stabilu mašīnlasāmu kodu. Piemēram, pieprasījums ar trūkstošiem vai nezināmiem akreditācijas datiem atgriež:

401 Unauthorized

{
  "type": "https://docs.livingsecurity.com/developers/v1/errors/unauthorized",
  "title": "Unauthorized",
  "status": 401,
  "detail": "No valid API credential was provided.",
  "code": "unauthorized",
  "request_id": "req_...",
  "doc_url": "https://docs.livingsecurity.com/developers/v1/errors/unauthorized",
  "retryable": false
}

Atzarojiet loģiku pēc code, nekad pēc detail. Izpildiet doc_url, lai uzzinātu risinājuma soļus, un, sazinoties ar atbalstu, norādiet request_id — tas atbilst Request-Id atbildes galvenei un Developer Hub pieprasījumu žurnāliem. Pilns kodu kopums ir kļūdu atsaucē.

Līguma versijas

Katra atbilde galvenē Living-Security-Version atbalsta to līguma versiju, kas to apkalpoja, kā arī galveni Request-Id korelācijai. Pieprasījumu varat piesaistīt publicētai līguma versijai pēc datuma:

curl --fail-with-body --connect-timeout 5 --max-time 30 \
  https://api.eu-west-1.livingsecurity.ai/v1/organization \
  -u "apikey:${LIVING_SECURITY_API_KEY:?Set LIVING_SECURITY_API_KEY}" \
  -H "Living-Security-Version: 2026-07-01"

Versija tiek noteikta šādā secībā: pieprasījuma galvene, ja tā ir norādīta, pretējā gadījumā pakalpojuma konta piesaistītā noklusējuma versija, pretējā gadījumā jaunākā publicētā versija. Pieprasot versiju, kas nav publicēta (vai kuras izbeigšanas datums ir pagājis), tiek atgriezts 400 ar kodu unsupported_version. Publicētās versijas un to izmaiņas ir uzskaitītas API izmaiņu žurnālā.

Pirmā pieprasījuma problēmu novēršana

Rezultāts	Nākamā darbība
`401 unauthorized`	Pārbaudiet noslēpumu, tā derīguma termiņu un organizācijas reģionu. Nemēģiniet citus resursdatorus ar aktīviem akreditācijas datiem.
`403 insufficient_permission`	Piešķiriet `organization:read` gan pakalpojuma kontam, gan tā atslēgai.
`400 unsupported_version`	Izvēlieties publicētu versiju no izmaiņu žurnāla.
`429 rate_limited`	Uzgaidiet `Retry-After`; izpildiet ierobežotā atkārtojuma piemēru.
Tīkla noildze	Pārbaudiet savienojamību un atkārtojiet šo lasīšanas pieprasījumu savas lietojumprogrammas atkārtojumu budžeta ietvaros.

Citu kļūdu gadījumā izpildiet atbildes doc_url. Saglabājiet Request-Id atbalstam; nekad neiekļaujiet Authorization galveni vai savu API atslēgu atbalsta pieteikumā.

Nākamie soļi

Reģioni

Izvēlieties organizācijai US vai EU /v1 resursdatoru.

Lapošana

Pārlūkojiet sarakstus ar page_token un saraksta apvalku.

Pieprasījumu ierobežojumi

Izprotiet pieprasījumu budžetus un apstrādājiet 429 atbildes.

Kļūdu atsauce

Visi kļūdu kodi, to HTTP statuss un risināšanas veids.

Developer Hub

Pārvaldiet pakalpojumu kontus, API atslēgas un pieprasījumu žurnālus.

Izstrādātāju centrs

Publiskais API v1

API v1 atsauce

Priekšnosacījumi

Akreditācijas datu izveide

Kā darbojas autentifikācija

Kļūdu atbilžu lasīšana

Līguma versijas

Pirmā pieprasījuma problēmu novēršana

Nākamie soļi

Reģioni

Lapošana

Pieprasījumu ierobežojumi

Kļūdu atsauce

Developer Hub

Izstrādātāju centrs

Publiskais API v1

API v1 atsauce

​Priekšnosacījumi

​Akreditācijas datu izveide

​Kā darbojas autentifikācija

​Kļūdu atbilžu lasīšana

​Līguma versijas

​Pirmā pieprasījuma problēmu novēršana

​Nākamie soļi

Reģioni

Lapošana

Pieprasījumu ierobežojumi

Kļūdu atsauce

Developer Hub

Priekšnosacījumi

Akreditācijas datu izveide

Kā darbojas autentifikācija

Kļūdu atbilžu lasīšana

Līguma versijas

Pirmā pieprasījuma problēmu novēršana

Nākamie soļi