API-quickstart

Opret en servicekonto og en API-nøgle i Developer Hub, og send derefter Deres første anmodning. Denne quickstart anvender API-nøgleautentificering; De behøver ikke en OAuth-klient. Se Autentificering, hvis Deres integration kræver kortlivede OAuth-adgangstokens.

Forudsætninger

Administratoradgang til Living Security Dashboard.
Developer Hub skal være synlig under Indstillinger → Integrationer & Developers → Developer Hub.

Opret legitimationsoplysninger

Opret en servicekonto

Åbn fanen Service accounts i Developer Hub, og opret en konto. Giv den et beskrivende navn (for eksempel reporting-pipeline), og tildel de tilladelser, som dens nøgler må anvende – til denne vejledning er organization:read tilstrækkeligt.Kontoens tilladelser udgør loftet for alle nøgler, der oprettes under den: en nøgle kan aldrig gøre mere, end dens servicekonto tillader.

Opret en API-nøgle

Åbn servicekontoens detaljeside, og opret en nøgle. Vælg de tilladelser, som netop denne nøgle har brug for (en delmængde af kontoens), samt en udløbsperiode – 30, 90 eller 365 dage eller en brugerdefineret periode. Udløb er obligatorisk.Nøglens hemmelighed begynder med lsk_live_ og vises kun én gang. Kopiér den straks til en secret manager; den kan ikke hentes igen senere.

Commit aldrig API-nøglehemmeligheder til versionsstyring, og indlejr dem aldrig i kode på klientsiden. Enhver, der er i besiddelse af hemmeligheden, kan handle med nøglens tilladelser.

Vælg Deres region

Kald den regionale /v1-host, der svarer til organisationens dataplacering. Nøgler autentificeres kun på den pågældende host.

Region	Base-URL
US	`https://api.us-east-1.livingsecurity.ai/v1`
EU	`https://api.eu-west-1.livingsecurity.ai/v1`

Se Regioner, hvis De er usikker på, hvilken host De skal bruge. En gyldig nøgle, der sendes til den anden region, fejler som unauthorized. Brug regionsrullemenuen i eksemplet nedenfor til at skifte host.

Send Deres første anmodning

Indlæs LIVING_SECURITY_API_KEY fra Deres secret manager i miljøet for den proces, der sender anmodningen. Eksemplerne nedenfor læser den uden at indlejre en hemmelighed i kildekoden. Til Python skal De først installere requests.Kald API’et med hemmeligheden i HTTP Basic-autentificeringens adgangskode- eller brugernavnsfelt – begge dele fungerer, så klienter, der kræver, at begge felter er udfyldt (f.eks. Power BI’s Web-connector), kan angive en pladsholder som apikey i det andet felt.

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())

Et vellykket svar returnerer Deres organisation:

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"
}

Hvis De modtager dette svar, fungerer Deres legitimationsoplysninger. Anmodningen vises også i fanen Request logs i Developer Hub inden for få øjeblikke.

Bearer-autentificering med den samme hemmelighed (Authorization: Bearer lsk_live_...) fungerer også. Basic-autentificering findes, så værktøjer, der kun understøtter brugernavn/adgangskode – som Power BI’s Web-connector – kan oprette forbindelse.

Sådan fungerer autentificering

Legitimationsoplysningerne afgør organisationen. /v1-anmodninger indeholder ingen tenant-vælger: intet organisationssegment i stien og ingen organisationsheader. Hvis der sendes en x-organization-id-header, afvises anmodningen med invalid_request. Hosten skal stadig svare til organisationens region. Se Regioner.
Tilladelser kontrolleres pr. operation. Hver /v1-operation kræver en navngivet tilladelse (for eksempel kræver GET /v1/organization organization:read). En nøgle, der mangler tilladelsen, får en 403 med koden insufficient_permission.
Nøgler udløber og kan roteres uden nedetid. Se API-nøgler for rotation med et overlapsvindue.

Læsning af fejlsvar

Hver /v1-fejl er application/problem+json (RFC 9457) med en stabil maskinlæsbar kode. En anmodning med manglende eller ukendte legitimationsoplysninger returnerer for eksempel:

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
}

Forgren på code, aldrig på detail. Følg doc_url for at få vist løsningstrinnene, og angiv request_id, når De kontakter support – den svarer til svarheaderen Request-Id og anmodningsloggene i Developer Hub. Det fulde kodesæt findes i fejlreferencen.

Kontraktversioner

Hvert svar angiver den kontraktversion, der har leveret det, i headeren Living-Security-Version sammen med en Request-Id-header til korrelation. De kan fastlåse en anmodning til en publiceret kontraktversion efter dato:

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"

Versionen fastlægges i denne rækkefølge: anmodningsheaderen, hvis den er til stede, ellers servicekontoens fastlåste standard, ellers den seneste publicerede version. Hvis der anmodes om en version, der ikke er publiceret (eller som har passeret sin udfasningsdato), returneres en 400 med koden unsupported_version. Publicerede versioner og deres ændringer er oplistet i API-ændringsloggen.

Fejlfinding af Deres første anmodning

Resultat	Næste handling
`401 unauthorized`	Kontrollér hemmeligheden, dens udløb og organisationens region. Prøv ikke andre hosts med en aktiv legitimation.
`403 insufficient_permission`	Tildel `organization:read` til både servicekontoen og dens nøgle.
`400 unsupported_version`	Vælg en publiceret version fra ændringsloggen.
`429 rate_limited`	Vent på `Retry-After`; følg eksemplet med begrænset genforsøg.
Netværkstimeout	Kontrollér forbindelsen, og gentag denne læsning inden for Deres applikations budget for genforsøg.

Ved andre fejl skal De følge svarets doc_url. Gem Request-Id til support; medtag aldrig Authorization-headeren eller Deres API-nøgle i en supportsag.

Næste trin

Regioner

Vælg US- eller EU-/v1-hosten for organisationen.

Paginering

Gennemgå lister med page_token og listekonvolutten.

Hastighedsgrænser

Forstå anmodningsbudgetter, og håndtér 429-svar.

Fejlreference

Alle fejlkoder, deres HTTP-status, og hvordan de løses.

Developer Hub

Administrer servicekonti, API-nøgler og anmodningslogge.

Udviklerhub

Offentlig API v1

API v1-reference

Forudsætninger

Opret legitimationsoplysninger

Sådan fungerer autentificering

Læsning af fejlsvar

Kontraktversioner

Fejlfinding af Deres første anmodning

Næste trin

Regioner

Paginering

Hastighedsgrænser

Fejlreference

Developer Hub

Udviklerhub

Offentlig API v1

API v1-reference

​Forudsætninger

​Opret legitimationsoplysninger

​Sådan fungerer autentificering

​Læsning af fejlsvar

​Kontraktversioner

​Fejlfinding af Deres første anmodning

​Næste trin

Regioner

Paginering

Hastighedsgrænser

Fejlreference

Developer Hub

Forudsætninger

Opret legitimationsoplysninger

Sådan fungerer autentificering

Læsning af fejlsvar

Kontraktversioner

Fejlfinding af Deres første anmodning

Næste trin