Kom i gang med API-et

Opprett en tjenestekonto og en API-nøkkel i Developer Hub, og send deretter din første forespørsel. Denne hurtigstarten bruker autentisering med API-nøkkel; du trenger ingen OAuth-klient. Se Autentisering hvis integrasjonen din krever kortlevde OAuth-tilgangstokener.

Forutsetninger

Administratortilgang til Living Security Dashbord.
Developer Hub synlig under Innstillinger → Integrasjoner & Developers → Developer Hub.

Opprett legitimasjon

Opprett en tjenestekonto

Åpne fanen Service accounts i Developer Hub og opprett en konto. Gi den et beskrivende navn (for eksempel reporting-pipeline) og gi den tillatelsene nøklene dens kan bruke – for denne veiledningen er organization:read tilstrekkelig.Kontoens tillatelser er taket for alle nøkler som opprettes under den: en nøkkel kan aldri gjøre mer enn tjenestekontoen tillater.

Opprett en API-nøkkel

Åpne tjenestekontoens detaljside og opprett en nøkkel. Velg tillatelsene akkurat denne nøkkelen trenger (en delmengde av kontoens) og en utløpstid – 30, 90 eller 365 dager, eller en egendefinert periode. Utløpstid er obligatorisk.Nøkkelens hemmelighet starter med lsk_live_ og vises én gang. Kopier den umiddelbart til en hemmelighetsbehandler (secret manager); den kan ikke hentes frem senere.

Du må aldri sjekke inn hemmeligheter for API-nøkler i versjonskontroll eller bygge dem inn i kode på klientsiden. Enhver som har hemmeligheten, kan handle med nøkkelens tillatelser.

Velg region

Kall den regionale /v1-verten som samsvarer med organisasjonens datalagringsplassering. Nøkler autentiseres kun på den verten.

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

Se Regioner hvis du er usikker på hvilken vert du skal bruke. En gyldig nøkkel som sendes til den andre regionen, feiler med unauthorized. Bruk regionvelgeren i eksempelet nedenfor for å bytte vert.

Send din første forespørsel

Last inn LIVING_SECURITY_API_KEY fra hemmelighetsbehandleren din i miljøet til prosessen som sender forespørselen. Eksemplene nedenfor leser den uten å bygge inn en hemmelighet i kildekoden. For Python må du installere requests først.Kall API-et med hemmeligheten i passord- eller brukernavnfeltet for HTTP Basic auth – begge fungerer, slik at klienter som krever at begge felt er fylt ut (for eksempel Power BIs Web-kobling) kan sette inn en plassholder som apikey i det andre feltet.

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 organisasjonen din:

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 du får dette svaret, fungerer legitimasjonen din. Forespørselen vises også i fanen Request logs i Developer Hub i løpet av kort tid.

Bearer-autentisering med samme hemmelighet (Authorization: Bearer lsk_live_...) fungerer også. Basic auth finnes slik at verktøy som bare støtter brukernavn/passord – som Power BIs Web-kobling – kan koble til.

Slik fungerer autentisering

Legitimasjonen bestemmer organisasjonen. /v1-forespørsler har ingen tenant-velger: ingen organisasjonssti og ingen organisasjonsheader. Hvis du sender en x-organization-id-header, avvises forespørselen med invalid_request. Verten må fortsatt samsvare med organisasjonens region. Se Regioner.
Tillatelser kontrolleres per operasjon. Hver /v1-operasjon krever en navngitt tillatelse (for eksempel krever GET /v1/organization organization:read). En nøkkel som mangler tillatelsen, får en 403 med kode insufficient_permission.
Nøkler utløper og kan roteres uten nedetid. Se API-nøkler for rotasjon med et overlappingsvindu.

Lese feilsvar

Hver /v1-feil er application/problem+json (RFC 9457) med en stabil maskinlesbar kode. En forespørsel med manglende eller ukjent legitimasjon 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 logikken på code, aldri på detail. Følg doc_url for fremgangsmåten for løsning, og oppgi request_id når du kontakter support – den samsvarer med svarheaderen Request-Id og forespørselsloggene i Developer Hub. Det fullstendige settet med koder finner du i feilreferansen.

Kontraktversjoner

Hvert svar gjentar kontraktversjonen som behandlet forespørselen i headeren Living-Security-Version, sammen med en Request-Id-header for korrelasjon. Du kan låse en forespørsel til en publisert kontraktversjon ved hjelp av 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"

Versjonen avgjøres i denne rekkefølgen: forespørselsheaderen hvis den finnes, ellers tjenestekontoens låste standardversjon, ellers den nyeste publiserte versjonen. Hvis du ber om en versjon som ikke er publisert (eller som har passert utfasingsdatoen), returneres en 400 med kode unsupported_version. Publiserte versjoner og endringene i dem er oppført i API-endringsloggen.

Feilsøk din første forespørsel

Resultat	Neste steg
`401 unauthorized`	Kontroller hemmeligheten, utløpstiden og organisasjonens region. Ikke prøv andre verter med gyldig legitimasjon.
`403 insufficient_permission`	Gi `organization:read` til både tjenestekontoen og nøkkelen.
`400 unsupported_version`	Velg en publisert versjon fra endringsloggen.
`429 rate_limited`	Vent på `Retry-After`; følg eksempelet med begrenset antall nye forsøk.
Tidsavbrudd i nettverket	Kontroller tilkoblingen og prøv denne lesingen på nytt innenfor applikasjonens budsjett for nye forsøk.

For andre feil følger du svarets doc_url. Ta vare på Request-Id for support; ta aldri med Authorization-headeren eller API-nøkkelen din i en henvendelse.

Neste steg

Regioner

Velg US- eller EU-/v1-verten for organisasjonen.

Paginering

Gå gjennom lister med page_token og listeomslaget.

Rate limits

Forstå forespørselsbudsjetter og håndter 429-svar.

Feilreferanse

Alle feilkoder, HTTP-statusen deres og hvordan de løses.

Developer Hub

Administrer tjenestekontoer, API-nøkler og forespørselslogger.

Utviklersenter

Offentlig API v1

API v1-referanse

Forutsetninger

Opprett legitimasjon

Slik fungerer autentisering

Lese feilsvar

Kontraktversjoner

Feilsøk din første forespørsel

Neste steg

Regioner

Paginering

Rate limits

Feilreferanse

Developer Hub

Utviklersenter

Offentlig API v1

API v1-referanse

​Forutsetninger

​Opprett legitimasjon

​Slik fungerer autentisering

​Lese feilsvar

​Kontraktversjoner

​Feilsøk din første forespørsel

​Neste steg

Regioner

Paginering

Rate limits

Feilreferanse

Developer Hub

Forutsetninger

Opprett legitimasjon

Slik fungerer autentisering

Lese feilsvar

Kontraktversjoner

Feilsøk din første forespørsel

Neste steg