> ## Documentation Index
> Fetch the complete documentation index at: https://docs.livingsecurity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Eldre offentlig API

> Vedlikehold eksisterende /api/v1-integrasjoner som bytter en API-tilgangsnøkkel mot et bearer-token.

Denne veiledningen omhandler eksisterende `/api/v1`-integrasjoner som bytter en API-tilgangsnøkkel mot et bearer-token. Legitimasjonen og forespørselsformatet skiller seg fra det offentlige API-et `/v1`.

For en ny integrasjon bør du starte med [API-hurtigstarten](/no/developers/v1/quickstart) og [Autentisering](/no/developers/v1/authentication). Det nye API-et `/v1` bruker API-nøkler for tjenestekontoer eller OAuth-tilgangstokener.

## Før du begynner

Du trenger:

* Living Security-tilgang som tillater administrasjon av API-tilgangsnøkler
* En API-tilgangsnøkkel opprettet under **Innstillinger → Access Keys**
* Den engangshemmeligheten for tilgangsnøkkelen som vises når legitimasjonen opprettes
* API-utsteder-ID-en (API issuer ID) som Living Security har levert sammen med legitimasjonen din for det offentlige API-et
* Den regionale basis-URL-en for organisasjonen du integrerer
* Et kjøremiljø på serversiden og en hemmelighetsbehandler

Hemmeligheter for tilgangsnøkler må ikke plasseres i nettleserkode, mobilapper, kildekontroll, miljøvariabler på klientsiden, saker eller delte logger.

<Note>
  Dialogen Access Keys viser engangshemmeligheten, men viser ikke API-utsteder-ID-en. Hvis Living Security ikke har levert utsteder-ID-en sammen med legitimasjonen din for det offentlige API-et, kan du be om den fra [Living Security-support](mailto:support@livingsecurity.com). Utsteder-ID-en er ikke det samme som tilgangsnøkkel-ID-en eller organisasjons-ID-en.
</Note>

## Regionale verter

Den eldre kontrakten bruker disse regionale produksjonsvertene for `/api/v1`:

| Region | Basis-URL |
| - | - |
| USA | `https://api.us-east-1.livingsecurity.ai/api/v1` |
| EU | `https://api.eu-west-1.livingsecurity.ai/api/v1` |

Bruk regionen som er tildelt Living Security-organisasjonen. Ikke bytt region for å omgå en autorisasjons- eller tilgjengelighetsfeil.

## Eldre ressurser

| Ressurs | Støttede operasjoner |
| - | - |
| **Mennesker** | Søke etter personer i organisasjonen og hente en persons medlemskap |
| **API-tilgangsnøkler** | Opprette, liste opp, rotere og tilbakekalle API-tilgangsnøkler |

Bruk **Developers → Public API Reference** for den fullstendige listen over operasjoner, parametere, forespørsler, svar og skjemaer. Hvis en operasjon ikke finnes der, er den ikke en del av det offentlige API-et for øyeblikket.

## Autentisering

Tilgang til det offentlige API-et skjer i to trinn:

1. Bytt den hemmelige tilgangsnøkkelen og API-utsteder-ID-en mot et kortlivet bearer-token og en organisasjons-ID.
2. Send bearer-tokenet og organisasjons-ID-en med hver API-forespørsel.

De påkrevde forespørselshodene er:

```http theme={null}
Authorization: Bearer <access-token>
x-organization-id: <organization-id>
```

Organisasjonshodet må være organisasjonen som returneres av utvekslingen av tilgangsnøkkelen. En nøkkel gir ikke tilgang til en vilkårlig organisasjons-ID.

### TypeScript SDK

Installer gjeldende hovedversjon:

```bash theme={null}
npm install @livingsecurity/sdk@^1
```

Bytt deretter nøkkelen og konfigurer SDK-et:

```typescript theme={null}
import { configure, exchangeAccessKey } from "@livingsecurity/sdk";

const accessKeySecret = process.env.LS_API_ACCESS_KEY_SECRET;
const apiIssuerId = process.env.LS_API_ISSUER_ID;

if (!accessKeySecret || !apiIssuerId) {
  throw new Error("LS_API_ACCESS_KEY_SECRET and LS_API_ISSUER_ID are required");
}

const { accessToken, organizationId } = await exchangeAccessKey(
  accessKeySecret,
  apiIssuerId,
);

configure({
  baseUrl: "https://api.us-east-1.livingsecurity.ai/api/v1",
  accessToken,
  organizationId,
});
```

Bruk EU-basis-URL-en for en EU-organisasjon. SDK-utvekslingen er beregnet på Node.js-kjøremiljøer på serversiden.

### Direkte REST-forespørsel

Hvis du utfører utvekslingen utenfor SDK-et, må du sende bearer-tokenet og organisasjons-ID-en med hver forespørsel:

```bash theme={null}
curl --request GET \
  "https://api.us-east-1.livingsecurity.ai/api/v1/people/search?limit=1" \
  --header "Authorization: Bearer $LIVING_SECURITY_BEARER_TOKEN" \
  --header "x-organization-id: $LIVING_SECURITY_ORG_ID" \
  --header "Accept: application/json"
```

Bearer-tokener er kortlivede. Bytt tilgangsnøkkelen på nytt når du skal hente et nytt token, i stedet for å lagre et bearer-token som permanent legitimasjon.

## Livssyklus for tilgangsnøkler

* Gi nøklene navn etter integrasjonen eller automatiseringen som eier dem.
* Velg de minst privilegerte omfangene (scopes) som tilbys i skjemaet for tilgangsnøkler.
* Lagre engangshemmeligheten umiddelbart. Den kan ikke hentes frem igjen etter opprettelse eller rotasjon.
* Roter en nøkkel via **Innstillinger → Access Keys**, og ta i bruk erstatningen før du tilbakekaller den gamle legitimasjonen.
* Tilbakekall nøkler som ikke lenger er i bruk, eller hvis hemmelighet kan ha blitt eksponert.
* Bruk nøkler for tjenestekontoer til ikke-menneskelige integrasjoner når denne nøkkeltypen er tilgjengelig for organisasjonen din.

## Paginering

Søk etter mennesker støtter parameterne `limit`, `cursor`, `offset` og `includeTotal`. Foretrekk markøren (cursor) som returneres av forrige svar ved sekvensiell gjennomgang.

* `limit` er som standard 50 og godtar 1–100.
* `cursor` fortsetter fra et tidligere svar.
* `offset` hopper over et antall poster og er som standard 0.
* `includeTotal=true` ber om et eksakt filtrert antall. Utelat den når antallet ikke er nødvendig.

Les objektet `pagination` som returneres av endepunktet. Ikke beregn neste side ut fra antall rader du har mottatt, og ikke kombiner uavhengig paginerte forespørsler og sorter de delvise resultatene selv.

## Feil

Dokumenterte JSON-feil har denne generelle formen:

```json theme={null}
{
  "statusCode": 400,
  "message": "Validation failed",
  "error": "Bad Request"
}
```

`message` kan være en streng eller en matrise med valideringsmeldinger.

| Status | Betydning | Respons |
| - | - | - |
| `400` | Ugyldige parametere eller ugyldig forespørselstekst | Rett opp de navngitte valideringsfeilene |
| `401` | Bearer-token mangler, er ugyldig eller er utløpt | Bytt tilgangsnøkkelen på nytt og prøv på nytt én gang |
| `403` | Legitimasjonen mangler tillatelse eller organisasjonstilgang | Kontroller nøkkelens omfang og organisasjonskontekst |
| `404` | Ressursen finnes ikke i den autoriserte organisasjonen | Kontroller ressurs-ID-en og organisasjonen |
| `408` | Forespørselen fikk tidsavbrudd | Prøv på nytt med begrenset eksponentiell backoff |
| `429` | Forespørselsgrensen er nådd | Vent minst så lenge som `Retry-After`, når den finnes |
| `5xx` | Midlertidig tjenestefeil | Prøv sikre lesinger på nytt med begrenset eksponentiell backoff |

Den kuraterte kontrakten publiserer for øyeblikket ikke én universell numerisk forespørselsgrense, og den garanterer ikke et svarhode med forespørsels-ID for hver operasjon. Noter UTC-tidspunkt, metode, sti, status og sanert svartekst når du kontakter support.

Ikke prøv automatisk på nytt operasjoner som oppretter, roterer, tilbakekaller eller sletter, med mindre operasjonen eksplisitt dokumenterer idempotens. Kontroller gjeldende ressurstilstand etter en uklar nettverksfeil.

## Kompatibilitet og utfasing

V1 utvikles som standard additivt. Klienter må ignorere ukjente felt i svar. En endring som bryter kompatibiliteten krever en dokumentert migreringsvei. Utfasede operasjoner blir værende i referansen med begrunnelse, erstatning når den finnes, og dato for avvikling i løpet av migreringsperioden.

Lås SDK-et til en kompatibel hovedversjon, og gå gjennom utgivelsesnotatene før du oppgraderer. Behandle den genererte Public API Reference, og ikke førstepartsklienter i appen, som den gyldige kilden for skjemaet.

## Offentlig API, MCP og webapplikasjonen

| Flate | Brukes til | Kompatibilitetsmodell |
| - | - | - |
| **Offentlig API** | Kundesystemer, partnere og ekstern automatisering | Stabile, versjonerte ressurser |
| **MCP** | Tillatelsesstyrt samhandling med KI-verktøy | Verktøykontrakter og kompakte strukturerte utdata |
| **Webapplikasjon** | Menneskelige arbeidsflyter i Living Security-produktet | Appeide kontrakter som kan utvikle seg med brukergrensesnittet |

Se [MCP-integrasjon](/no/integrations/mcp) for å koble et KI-verktøy til Living Security.

## Få hjelp

Kontakt [Living Security-support](mailto:support@livingsecurity.com) med:

* Organisasjon og region
* SDK-navn og versjon, hvis det brukes
* UTC-tidsstempel, metode og sti
* HTTP-status og sanert feiltekst

Ta aldri med hemmeligheter for tilgangsnøkler, bearer-tokener eller private kundedata.

## Relatert

<CardGroup cols={2}>
  <Card title="API-tilgangsnøkler" icon="key" href="/no/integrations/api-keys">
    Opprett, roter og tilbakekall API-legitimasjon.
  </Card>

  <Card title="MCP-integrasjon" icon="robot" href="/no/integrations/mcp">
    Koble til støttede KI-verktøy via Model Context Protocol.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.