Skip to main content
Denne vejledning omhandler eksisterende /api/v1-integrationer, der udveksler en API-adgangsnøgle til et bearer-token. Deres legitimationsoplysninger og anmodningsformat adskiller sig fra den offentlige /v1-API. Til en ny integration bør du starte med API-hurtigstarten og Godkendelse. Den nye /v1-API anvender API-nøgler til servicekonti eller OAuth-adgangstokens.

Før du begynder

Du skal bruge:
  • Living Security-adgang, der tillader administration af API-adgangsnøgler
  • En API-adgangsnøgle oprettet under Indstillinger → Access Keys
  • Den engangshemmelighed for adgangsnøglen, der vises, når legitimationsoplysningen oprettes
  • API-udsteder-ID’et, som Living Security har leveret sammen med dine legitimationsoplysninger til den offentlige API
  • Den regionale basis-URL for den organisation, du integrerer
  • Et serverside-runtimemiljø og en secret manager
Hemmeligheder til adgangsnøgler må ikke placeres i browserkode, mobilapps, kildekodestyring, miljøvariabler på klientsiden, tickets eller delte logfiler.
Dialogboksen Access Keys viser engangshemmeligheden, men ikke API-udsteder-ID’et. Hvis Living Security ikke har leveret udsteder-ID’et sammen med dine legitimationsoplysninger til den offentlige API, kan du anmode om det hos Living Security Support. Udsteder-ID’et er ikke det samme som adgangsnøgle-ID’et eller organisations-ID’et.

Regionale værter

Den ældre kontrakt bruger disse regionale /api/v1-produktionsværter: Brug den region, der er tildelt Living Security-organisationen. Skift ikke region for at omgå en autorisations- eller tilgængelighedsfejl.

Ældre ressourcer

Brug Developers → Public API Reference for den komplette liste over operationer, parametre, anmodninger, svar og skemaer. Hvis en operation ikke findes dér, er den ikke en del af den offentlige API i øjeblikket.

Godkendelse

Adgang til den offentlige API sker i to trin:
  1. Udveksl den hemmelige adgangsnøgle og API-udsteder-ID’et til et kortvarigt bearer-token og et organisations-ID.
  2. Send bearer-tokenet og organisations-ID’et med hver API-anmodning.
De påkrævede anmodningshoveder er:
Organisationshovedet skal være den organisation, der returneres ved udvekslingen af adgangsnøglen. En nøgle giver ikke adgang til et vilkårligt organisations-ID.

TypeScript SDK

Installer den aktuelle hovedversion:
Udveksl derefter nøglen, og konfigurer SDK’et:
Brug EU-basis-URL’en til en EU-organisation. SDK-udvekslingen er beregnet til Node.js-runtimemiljøer på serversiden.

Direkte REST-anmodning

Hvis du udfører udvekslingen uden for SDK’et, skal du sende dets bearer-token og organisations-ID med hver anmodning:
Bearer-tokens er kortvarige. Udveksl adgangsnøglen igen, når du skal bruge et nyt token, i stedet for at gemme et bearer-token som en permanent legitimationsoplysning.

Livscyklus for adgangsnøgler

  • Navngiv nøgler efter den integration eller automatisering, der ejer dem.
  • Vælg de mindst privilegerede scopes, som formularen til adgangsnøgler tilbyder.
  • Gem engangshemmeligheden med det samme; den kan ikke hentes efter oprettelse eller rotation.
  • Roter en nøgle via Indstillinger → Access Keys, og udrul erstatningen, før du tilbagekalder den gamle legitimationsoplysning.
  • Tilbagekald nøgler, der ikke længere bruges, eller hvis hemmelighed kan være blevet eksponeret.
  • Brug servicekontonøgler til ikke-menneskelige integrationer, når den nøgletype er tilgængelig for din organisation.

Paginering

Personsøgning understøtter parametrene limit, cursor, offset og includeTotal. Brug helst den cursor, der returneres af det foregående svar, ved sekventiel gennemgang.
  • limit er som standard 50 og accepterer 1–100.
  • cursor fortsætter fra et tidligere svar.
  • offset springer et antal poster over og er som standard 0.
  • includeTotal=true anmoder om et nøjagtigt filtreret antal; udelad den, når antallet ikke er nødvendigt.
Læs det pagination-objekt, som endpointet returnerer. Beregn ikke den næste side ud fra antallet af modtagne rækker, og kombiner ikke uafhængigt paginerede anmodninger for selv at sortere de delvise resultater.

Fejl

Dokumenterede JSON-fejl har denne generelle form:
message kan være en streng eller en række valideringsmeddelelser. Den kuraterede kontrakt offentliggør i øjeblikket hverken én universel numerisk grænse for antal anmodninger eller garanterer et svarhoved med anmodnings-ID for alle operationer. Notér UTC-tidspunkt, metode, sti, status og det rensede svarindhold, når du anmoder om support. Forsøg ikke automatisk at gentage operationer til oprettelse, rotation, tilbagekaldelse eller sletning, medmindre operationen eksplicit dokumenterer idempotens. Kontrollér ressourcens aktuelle tilstand efter en uklar netværksfejl.

Kompatibilitet og udfasning

V1 udvikles som udgangspunkt additivt. Klienter skal ignorere ukendte svarfelter. En ændring, der bryder kompatibiliteten, kræver en dokumenteret migreringssti; udfasede operationer forbliver i referencen med årsag, erstatning når den findes, og ophørsdato i migreringsperioden. Fastlås SDK’et til en kompatibel hovedversion, og gennemgå dets udgivelsesnoter, før du opgraderer. Betragt den genererede Public API Reference – ikke førstepartsklienter i appen – som den autoritative kilde til skemaet.

Offentlig API, MCP og webapplikationen

Se MCP-integration for at forbinde et AI-værktøj til Living Security.

Få hjælp

Kontakt Living Security Support med:
  • Organisation og region
  • SDK-navn og -version, hvis det bruges
  • UTC-tidsstempel, metode og sti
  • HTTP-status og renset fejlindhold
Medsend aldrig hemmeligheder til adgangsnøgler, bearer-tokens eller private kundedata.

Relateret

API-adgangsnøgler

Opret, roter og tilbagekald API-legitimationsoplysninger.

MCP-integration

Forbind understøttede AI-værktøjer via Model Context Protocol.