API-snabbstart

Skapa ett tjänstkonto och en API-nyckel i Developer Hub och gör sedan din första begäran. Den här snabbstarten använder autentisering med API-nyckel; du behöver ingen OAuth-klient. Se Autentisering om er integration kräver kortlivade OAuth-åtkomsttoken.

Förutsättningar

Administratörsåtkomst till Living Security Instrumentpanel.
Developer Hub synligt under Inställningar → Integrationer & Developers → Developer Hub.

Skapa autentiseringsuppgifter

Skapa ett tjänstkonto

Öppna fliken Service accounts i Developer Hub och skapa ett konto. Ge det ett beskrivande namn (till exempel reporting-pipeline) och bevilja de behörigheter som dess nycklar får använda – för den här guiden räcker organization:read.Kontots behörigheter utgör taket för varje nyckel som skapas under det: en nyckel kan aldrig göra mer än vad dess tjänstkonto tillåter.

Skapa en API-nyckel

Öppna tjänstkontots detaljsida och skapa en nyckel. Välj de behörigheter som just den här nyckeln behöver (en delmängd av kontots) och en giltighetstid – 30, 90 eller 365 dagar, eller en anpassad period. Giltighetstid är obligatoriskt.Nyckelns hemlighet börjar med lsk_live_ och visas en enda gång. Kopiera den till en hemlighetshanterare direkt; den kan inte hämtas senare.

Checka aldrig in API-nyckelhemligheter i versionshantering och bädda inte in dem i kod på klientsidan. Alla som har hemligheten kan agera med nyckelns behörigheter.

Välj region

Anropa den regionala /v1-värden som motsvarar organisationens dataplacering. Nycklar autentiseras endast på den värden.

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

Se Regioner om du är osäker på vilken värd som ska användas. En giltig nyckel som skickas till den andra regionen misslyckas som unauthorized. Använd regionlistan i exemplet nedan för att byta värd.

Gör din första begäran

Läs in LIVING_SECURITY_API_KEY från din hemlighetshanterare i miljön för den process som gör begäran. Exemplen nedan läser den utan att bädda in en hemlighet i källkoden. För Python ska du först installera requests.Anropa API:et med hemligheten i lösenordsfältet eller användarnamnsfältet för HTTP Basic-autentisering – båda fungerar, så klienter som kräver att båda fälten fylls i (som Power BI:s Web-anslutning) kan ange en platshållare som apikey i det andra fältet.

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

Ett lyckat svar returnerar din 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"
}

Om du får det här svaret fungerar dina autentiseringsuppgifter. Begäran visas också i fliken Request logs i Developer Hub inom några ögonblick.

Bearer-autentisering med samma hemlighet (Authorization: Bearer lsk_live_...) fungerar också. Basic-autentisering finns så att verktyg som bara hanterar användarnamn/lösenord – som Power BI:s Web-anslutning – kan ansluta.

Så fungerar autentisering

Autentiseringsuppgiften avgör organisationen. /v1-begäranden innehåller ingen klientväljare: inget organisationssegment i sökvägen och ingen organisationshuvud. Om en x-organization-id-header skickas avvisas begäran med invalid_request. Värden måste fortfarande motsvara organisationens region. Se Regioner.
Behörigheter kontrolleras per operation. Varje /v1-operation kräver en namngiven behörighet (till exempel kräver GET /v1/organization organization:read). En nyckel som saknar behörigheten får ett 403 med kod insufficient_permission.
Nycklar upphör att gälla och kan roteras utan driftavbrott. Se API-nycklar för rotation med ett överlappande tidsfönster.

Läsa felsvar

Varje /v1-fel är application/problem+json (RFC 9457) med en stabil maskinläsbar kod. Till exempel returnerar en begäran med saknad eller okänd autentiseringsuppgift:

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
}

Grena på code, aldrig på detail. Följ doc_url för lösningsstegen och ange request_id när du kontaktar supporten – det motsvarar svarshuvudet Request-Id och Developer Hubs begäranloggar. Den fullständiga kodlistan finns i felreferensen.

Kontraktsversioner

Varje svar återger den kontraktsversion som levererade det i headern Living-Security-Version, tillsammans med en Request-Id-header för korrelation. Du kan låsa en begäran till en publicerad kontraktsversion med datum:

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 avgörs i följande ordning: begäranhuvudet om det finns, annars tjänstkontots låsta standardversion, annars den senast publicerade versionen. Om en version som inte är publicerad (eller som har passerat sitt slutdatum) begärs returneras ett 400 med kod unsupported_version. Publicerade versioner och deras ändringar listas i API-ändringsloggen.

Felsök din första begäran

Resultat	Nästa åtgärd
`401 unauthorized`	Kontrollera hemligheten, dess giltighetstid och organisationens region. Prova inte andra värdar med en aktiv autentiseringsuppgift.
`403 insufficient_permission`	Bevilja `organization:read` till både tjänstkontot och dess nyckel.
`400 unsupported_version`	Välj en publicerad version från ändringsloggen.
`429 rate_limited`	Vänta på `Retry-After`; följ exemplet med begränsade omförsök.
Nätverkstimeout	Kontrollera anslutningen och försök läsa igen inom programmets budget för omförsök.

För andra fel, följ svarets doc_url. Spara Request-Id för supporten; inkludera aldrig Authorization-huvudet eller din API-nyckel i ett ärende.

Nästa steg

Regioner

Välj US- eller EU-/v1-värden för organisationen.

Sidindelning

Gå igenom listor med page_token och listomslaget.

Hastighetsgränser

Förstå begäransbudgetar och hantera 429-svar.

Felreferens

Varje felkod, dess HTTP-status och hur den åtgärdas.

Developer Hub

Hantera tjänstkonton, API-nycklar och begäranloggar.

Utvecklarportal

Publikt API v1

API v1-referens

Förutsättningar

Skapa autentiseringsuppgifter

Så fungerar autentisering

Läsa felsvar

Kontraktsversioner

Felsök din första begäran

Nästa steg

Regioner

Sidindelning

Hastighetsgränser

Felreferens

Developer Hub

Utvecklarportal

Publikt API v1

API v1-referens

​Förutsättningar

​Skapa autentiseringsuppgifter

​Så fungerar autentisering

​Läsa felsvar

​Kontraktsversioner

​Felsök din första begäran

​Nästa steg

Regioner

Sidindelning

Hastighetsgränser

Felreferens

Developer Hub

Förutsättningar

Skapa autentiseringsuppgifter

Så fungerar autentisering

Läsa felsvar

Kontraktsversioner

Felsök din första begäran

Nästa steg