> For the complete documentation index, see [llms.txt](https://docs.cerrix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/admin-settings/api-key-management-and-setup.md).
# Administrasjon og oppsett av API-nøkler
Dette dokumentet forklarer hvordan du genererer og konfigurerer API-nøkler for å koble eksterne applikasjoner til CERRIX-API-ene. CERRIX API-manualene beskriver tilgjengelige endepunkter og nyttelastformater. Denne veiledningen fokuserer på **trinnene som kreves for å opprette og administrere API-legitimasjon på en sikker måte**.
## **1. Opprett en ny API-nøkkel**
1. Logg inn på CERRIX.
2. Øverst til høyre klikker du på din **navn**.
3. Velg **Vis profil**.\
4. Gå til i menyen til venstre **API-nøkler**.
5. Klikk **Legg til** for å opprette en ny API-nøkkel.\
6. Angi en beskrivende **Navn** for API-nøkkelen.
7. Den **utløpsdato** for en API-nøkkel kan konfigureres, men det finnes en maksimumsgrense: den **kan ikke settes til lenger enn ett år** fra opprettelsesdatoen. Du kan forkorte denne perioden hvis ønskelig, men ikke forlenge den utover maksimumsgrensen på ett år.
## **2. Konfigurer tillatte IP-adresser**
For å forbedre sikkerheten kan API-nøkler begrenses til bestemte IP-adresser.
1. Under **Tillatte IP-adresser**, klikk **Legg til**.
2. Angi IP-adressen til serveren eller systemet som skal bruke denne API-nøkkelen.
* Dette bør vanligvis være IP-adressen til systemet der integrasjonen eller applikasjonen din skal kjøre.
* For testformål kan du også bruke din egen IP-adresse. *(Bekreft med administratoren din hvilken IP som er riktig.)*
## **3. Velg tilgjengelige API-er**
Når du oppretter en API-nøkkel, kan du definere hvilke API-er nøkkelen er autorisert til å kalle.
1. Velg API-ene du vil at denne nøkkelen skal ha tilgang til, på konfigurasjonsskjermen for API-nøkkelen.
2. Bare de valgte API-ene kan nås med denne nøkkelen. Dette gjør at du kan følge prinsippet om minste privilegium.
## **4. Lagre og hent legitimasjonen**
1. Klikk **Lagre** for å opprette API-nøkkelen.
2. Når den er lagret, genererer systemet:
* **Identifier**
* **Passord**
{% hint style="warning" %}
**Viktig:** Dette er den **eneste gangen** denne legitimasjonen vises. Av sikkerhetsgrunner kan den ikke hentes senere.
* Kopier Identifier og passordet umiddelbart.
* Lagre dem sikkert i integrasjonsapplikasjonen eller en sikker passordbehandler.
Hvis du mister legitimasjonen, må du generere en ny API-nøkkel.
{% endhint %}
## **5. Bruke API-nøkkelen**
Bruk den genererte **Identifier** og **Passord** for å autentisere forespørslene dine som beskrevet i [CERRIX API-manualer](/cerrix-documentation-no/cerrix-funksjoner/admin-settings/api-documentation.md). Sørg for at:
* IP-adressen til det kallende systemet samsvarer med én av de tillatte IP-adressene.
* API-nøkkelen har fått tilgang til endepunktene du har til hensikt å kalle.
## Påkrevd rolle og hvor API-nøkler opprettes
Administrasjon av API-nøkler krever **Applikasjonsadministrator** -rollen.
API-nøkler opprettes alltid fra din egen brukerprofil — klikk på din **navn** øverst til høyre, velg **Vis profil**, og åpne **API-nøkler**. De blir **ikke** administrert gjennom brukeradministrasjon, og hver nøkkel tilhører profilen som opprettet den.
## Tilgang til DirectData-endepunkter
DirectData-endepunktene (for eksempel DirectData-datasettene General, Risiko, Kontroll og BIM) returnerer **alle data som finnes i CERRIX-miljøet, uten filtrering etter roller eller tillatelser**. I motsetning til selve applikasjonen blir utdataene ikke avgrenset til den kallende brukerens organisasjoner eller modulroller.
Fordi svaret alltid inneholder hele datasettet, kan DirectData-endepunktene bare kalles med en API-nøkkel som tilhører en bruker med **Applikasjonsadministrator** rollen. Det finnes ingen rolle eller tillatelsessett med lavere privilegier som gir tilgang til DirectData.
På selve API-nøkkelen styres DirectData-tilgang av én enkelt innstilling: **Hent direkte data**, oppført under **Generelle API-er → Data-API-er** i nøkkelkonfigurasjonen. Aktivering gir nøkkelen tilgang til DirectData-endepunktene for **alle moduler** — DirectData-tilgang kan ikke begrenses til individuelle moduler.
For en rapporteringsintegrasjon som leser DirectData, bør kontoens omfang begrenses mest mulig:
* Bruk en dedikert tjenestekonto i stedet for en personlig konto (se *Tjenestekontoer og automatisering* nedenfor).
* Aktiver **Hent direkte data** bare på nøkler som brukes av rapporteringsintegrasjonen, og la API-er som integrasjonen ikke trenger, forbli uvalgt.
* Begrens nøkkelen til integrasjonsserverens IP-adresser, og hold utløpsperioden kort.
## Tjenestekontoer og automatisering
CERRIX autentiserer API-kall med en **API-nøkkel (Identifier + passord)** som er knyttet til en brukerprofil. Den bruker ikke en separat modell for klient-ID / klienthemmelighet, så det finnes ingen frittstående «applikasjons»-legitimasjon uavhengig av en bruker.
For uovervåkede integrasjoner (for eksempel et Power BI-uttrekk eller en oppgaveautomatiseringsbot) er det anbefalte mønsteret:
1. Opprett en vanlig CERRIX-brukerkonto, ideelt sett knyttet til en **felles teaminnboks** i stedet for en enkeltpersons postkasse.
2. Gi den kontoen bare de privilegiene integrasjonen trenger.
3. Opprett API-nøkkelen under den kontoen.
Fordi nøkkelen er knyttet til en ikke-personlig konto, administreres den sentralt og fortsetter å fungere når enkeltansatte byttes ut.
{% hint style="info" %}
En bruker uten e-postadresse kan opprettes, men en **API-nøkkel kan ikke opprettes for en slik bruker** — kontoen trenger en postkasse. En programvarerobot (RPA-bot) kan få sin egen konto og nøkkel etter de samme reglene, avhengig av tilgjengelige endepunkter (for eksempel finnes det for øyeblikket ikke noe API for å opprette testplaner).
{% endhint %}
## Overføre en nøkkel når eieren slutter
API-nøkler er bundet til en individuell brukerprofil. De **kan ikke overføres** til en annen bruker, og legitimasjonen vises bare én gang ved opprettelse, så en eksisterende nøkkel kan ikke overleveres.
Når eieren av en nøkkel forlater organisasjonen, bør etterfølgeren:
1. Opprette en **ny nøkkel under sin egen profil** (øverst til høyre → Vis profil → API-nøkler).
2. Konfigurere den med de **samme tillatte IP-adressene og endepunkttillatelsene**, og angi en utløpsdato (maksimalt ett år).
3. Kjør begge nøklene **side om side** under overgangen, og avvikle deretter den gamle nøkkelen når integrasjonen bruker den nye.
## Roller og skriveendepunkter (POST)
API-tillatelsene du velger på en API-nøkkel, dekker leseoperasjonene i modulene de tilhører. Skriveoperasjoner — for eksempel `POST /taskdata/v1/tasks`, `POST /taskdata/v1/tasks/{guid}` og `POST /taskdata/v1/tasks/{guid}/add/document`, som brukes til å laste opp prøver og opprette oppgaver for opplasting av bevis, testere og kontrollører — tilbys ikke som separate valgbare tillatelser på nøkkelen.
Disse kallene utføres med en API-nøkkel som tilhører en bruker med **Applikasjonsadministrator** rollen. Som med DirectData-endepunktene beskrevet ovenfor, finnes det for øyeblikket ingen rolle med lavere privilegier som gir tilgang til skriveendepunktene.
Når du setter opp en slik integrasjon, bør du holde kontoens omfang så lite som mulig:
* Opprette en **dedikert tjenestekonto** for integrasjonen i stedet for å bruke en personlig konto (se *Tjenestekontoer og automatisering* ovenfor), og reserver den kun for integrasjonen.
* Begrens nøkkelen til **IP-adressene til integrasjonsserveren**, og angi en utløpsdato (maksimalt ett år).
* Gi nøkkelen bare API-tillatelsene som integrasjonen faktisk kaller, og roter den etter en fast tidsplan.
{% hint style="info" %}
Muligheten til å gi API-skrivetilgang uten den fullstendige rollen Application Administrator er et anerkjent ønske. Hvis integrasjonen din trenger det, send inn eller stem på ideen i [CERRIX Community](https://community.cerrix.com) — kundebehov er det som styrer prioriteringen — og gi CERRIX-support beskjed om brukstilfellet ditt, slik at vi kan gi råd om det beste oppsettet i mellomtiden.
{% endhint %}
## Feilsøking av API-tilkoblinger
Bruk kontrollene nedenfor når en API-tilkobling mislykkes.
{% hint style="warning" %}
Del aldri en fullstendig `Authorization` -header eller API-legitimasjonen din i en supporthenvendelse eller e-post. Hvis legitimasjonen har blitt eksponert, generer nøkkelen på nytt.
{% endhint %}
**Akseptanse og produksjon er separate miljøer, hvert med sine egne nøkler.** En nøkkel som er opprettet i akseptanse, er ikke gyldig i produksjon, selv med identisk kode. Opprett nøkkelen mens du er logget inn i miljøet du har til hensikt å kalle, og bekreft at den kallende IP-adressen er tillatt for nøkkelen i det miljøet.
Vanlige feil:
* **400 – «No authenticationScheme was specified»**: kallet sender ikke Basic-autentisering. Bekreft at både API Key (Identifier) og Password er oppgitt. For å isolere problemet kan du teste et annet DirectData-endepunkt, for eksempel `/api/directdata/v1/risiko`.
* **401 Unauthorized / «credentials invalid» / «credentials provided for the Web source are invalid»**: CERRIX godtar ikke lenger nøkkelen. De vanlige årsakene er en **utløpt nøkkel** (nøkler er gyldige i maksimalt ett år), en nøkkel som ble tilbakekalt eller opprettet på nytt, eller en endring i tillatte IP-adresser. Merk at en skybasert BI-oppdatering kan kalle fra en annen IP enn et skrivebordsverktøy. Kontroller nøkkelen din under Vis profil → API-nøkler, og opprett en ny hvis den har utløpt.
* **Tilkoblingsfeil (for eksempel ved tilkobling fra Power BI)**: dette skyldes vanligvis myk IP-hvitelisting. Åpne profilens **API** side, godkjenn den kallende IP-adressen under **Forespurte IP-adresser**, og klikk **Lagre**.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.cerrix.com/cerrix-documentation-no/cerrix-funksjoner/admin-settings/api-key-management-and-setup.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
