> 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-documentation.md). # API-dokumentasjon Du finner CERRIX API-dokumentasjonen direkte i plattformen ved å klikke på :question:ikonet øverst til høyre i plattformen, og deretter klikke på "Manualer"
Deretter går du til API-manualen. Her vil du se en oversikt over alle støttede API-endepunkter.
## Å velge riktig endepunkt for rapportering API-manualen i plattformen lister opp hvert endepunkt, men et vanlig spørsmål er *hvilket* endepunkt som skal brukes for et gitt rapporteringsbehov. Den viktigste forskjellen er mellom **Workflow-endepunkter** og **rapporteringsdatasett (DirectData)**. * **Workflow-endepunkter er ikke for rapportering.** Per-Kontroll Workflow-endepunkter som for eksempel *Hent testinformasjon* finnes bare for å drive Workflowet for kontrolltesting for én enkelt Kontroll. De kan ikke brukes til å rapportere på tvers av mange Kontroller. For rapportering på kontrolltesting (for eksempel teststart- og testsluttdatoer på tvers av Kontroller), bruk **DirectData Kontroll / Testing** datasettene i stedet. * **Reviewer-resultater** (hvilken Reviewer som utførte en testplan-gjennomgang, gjennomgangsscoren og tidsstempelet) er ikke tilgjengelige i Workspace-eksporter, men et dedikert API-datasett returnerer **ReviewerGUID, gjennomgangsscore og tidsstempel**. * **MoI-statushistorikk** — den samme oversikten som Excel *"MoI-er og kommentarer"* nedlasting — er tilgjengelig via et dedikert MoI-kommentar-API-endepunkt, slik at oversikten over statushistorikken kan gjenoppbygges automatisk. {% hint style="info" %} Det finnes for øyeblikket **ingen API for å liste hvilke kontroller som er konfigurert i en ekstern tilkobling**. Alternativene er å kjøre forespørselen uten et Identifier-filter, eller å sjekke veiviseren for ekstern tilkobling i CERRIX-brukergrensesnittet. {% endhint %} ## Risiko-API-versjoner (V1, V2, V3) V1-, V2- og V3 Risiko-API-ene returnerer **de samme underliggende risikodataene**. Versjonene finnes på grunn av en endring i hvordan rotårsak / Hendelse-kategori for en Risiko registreres. For bakgrunnen til denne endringen, se utgivelsesnotatene. **V1 → V2: kun et navnebytte.** Feltet kalt *"Hendelseskategori"* i V1 ble omdøpt til *"Rotårsakkategori"* i V2. Det er den samme enkeltverdien under et nytt navn. Dette påvirker: * Risiko-endepunktene (`/risikodata/v{version}/risiko`, `/riskcontrol`, `/riskcontrolmois`): `hendelseskategori` ble `rotårsakKategori`. * DirectData-risikoendepunktet (`/directdata/v{version}/risiko`): `HendelseKategoriId` ble `RotårsakKategoriId`. * Selve stamdata-endepunktet ble omdøpt fra `/directdata/v1/risikohendelsekategori` ("Risiko Hendelse Kategori") til `/directdata/v2/risikorotårsakkategori` ("Risiko Root Cause Category"). **V2 → V3: grunnårsakskategorien ble flervalg.** I V3 kan en Risiko knyttes til **flere** grunnårsakskategorier i stedet for bare én, så de relevante API-ene returnerer nå flere verdier i stedet for én enkelt: * Risiko-endepunktene returnerer `rootCauseCategories` (flertall) i stedet for `rotårsakKategori`. * DirectData Risiko-endepunktet returnerer `RootCauseCategoryIds` som en rekke verdier i stedet for den enkelte `RotårsakKategoriId`. {% hint style="success" %} For nye integrasjoner, bruk **V3** så du har den nyeste versjonen. {% endhint %} ## Avvik-endepunkter og innkommende registreringer API-et støtter Avvik i begge retninger: eksterne systemer kan **opprette** Avvik i CERRIX, og rapporteringsverktøy kan **hente** dem. ### Opprette avvik fra eksterne verktøy Bruk **POST Avvik** endepunktet for å registrere avvik automatisk fra eksterne systemer — for eksempel et IT-tjenestehåndteringsverktøy der avvik også logges. Generer API-nøkkelen fra en **tjenestekonto**, slik at integrasjonen kjører under sin egen identitet i stedet for under en personlig brukerkonto. ### Hente avvik for rapportering Den **DirectData-datasett for avvik** (avvik, klassifiseringer, avvikstyper, egendefinerte felt og verdier, og tilknyttede MoI-er) returnerer avviksdataene dine til rapporteringsverktøy som Power BI. API-flaten fokuserer på å opprette og hente avvik; endringer i eksisterende avvik gjøres i selve applikasjonen. Planlegg større øvelser, som omkartlegging av avvik til en ny struktur for grunnårsakskategorier, som en aktivitet i avviksoversikten. ### Registrere innsendelser fra eksterne skjemaer Med **POST skjemasvar** endepunktet kan du mate inn innsendinger fra et eksternt skjemaverktøy i et CERRIX-skjema, slik at alle ansatte kan rapportere et avvik mens bare avviksteamet ditt jobber i CERRIX — innsenderne trenger ikke sin egen CERRIX-konto. Også her genererer du API-nøkkelen fra en tjenestekonto. To punkter å ta hensyn til når du utformer det eksterne skjemaet: * Knytt spørsmålene i skjemaet til vanlige felt; strukturfelter i CERRIX, som valg av Organisasjon, settes av avviksteamet ditt når registreringen behandles. * Ta med et navnespørsmål i skjemaet slik at innsenderne kan identifisere seg selv, siden selve innsendingen registreres under tjenestekontoen. For hjelp til å designe en innkommende integrasjon, kontakt CERRIX-support via servicedesken. ## Direct Data-datasett per modul Direct Data-endepunktene (`/directdata/v1/...`) returnerer normaliserte datasett for rapporteringsverktøy som Power BI. Ved siden av datasettene for Risiko, Kontroll og kontrolltesting, MoI-er, Tredjepart, oppgaver og brukere er følgende moduler tilgjengelige: * **Avvik** — avvik (inkludert registreringsdatoen og GUID-ene til tilknyttede MoI-er, Risiko og Kontroll), klassifiseringer, avvikstyper, egendefinerte felt for avvikstype og verdiene deres, samt avvik-MoI-er. * **Revisjon** — `GET /directdata/v1/revisjon` returnerer Revisjonene dine med deres Identifier, navn, mål, begrunnelse, konklusjon, plan, status, type, kritikalitet, konfidensialitet og poengsum, sammen med den tilknyttede Funnrapporten, tredjeparter, risikoer, kontroller, universobjekter, organisasjoner, forretningsdimensjoner, rammeverksdimensjoner og personene som er involvert (sponsorer, revisjonsobjekter, revisorer, kontrollører og ansvarlige for internrevisjon). `GET /directdata/v1/auditfinding` returnerer én rad per revisjonsfunn — beskrivelse, grunnårsak, anbefaling, alvorlighetsgrad, kommentar, ledelsens respons og status — inkludert oppfølginger, tilknyttede MoI-er og den overordnede revisjonen å koble på. Revisjonsgrunndataene (revisjonstype, observasjonsscorer per revisjonstype, revisjonsscore, kritikalitet, konfidensialitet, funn-alvorlighetsgrad, oppfølging av funn og Workflow) og egendefinerte felt for revisjonskontekst og vurdering av revisjonsrisiko er tilgjengelige som separate endepunkter. * **Databehandling** — ett endepunkt for Databehandling-detaljene, inkludert de tilknyttede MoI-ene, Risiko og Kontroll, og ett for de forvaltede datastrukturene. Der ingen system er konfigurert, inneholder svaret en kommentar som forklarer verdien "No system". * **Forretningsvurderinger** — Organisasjon, Forretningsdimensjon, Reviewer, gjennomgangsfrekvens, initialdato og neste gjennomgangsdato, og per gjennomgang dato for gjennomgang, score, Reviewer og kommentar. Grunndataene for vurderingsscore har sitt eget endepunkt. * **KPI/KRI** — alle KPI-er og KRI-er (inkludert deres rammedimensjoner) og dataverdiene deres. * **Tredjepart og kontrakter** — Tredjepart (inkludert rammedimensjoner), kontrakter (inkludert kontraktens GUID og oppsigelsestiden som tall og enhet), og definisjonene og verdiene for egendefinerte felt for både Tredjepart og kontrakter. * **MoIs** — ett endepunkt per MoI-type (Risiko, Kontroll, Hendelse, Avvik, Tredjepart, databehandling og BIM), hvert med status og opprinnelig forfallsdato; BIM-MoI-endepunktet returnerer også rammedimensjonene. De nøyaktige feltene og parameterne for hvert datasett er beskrevet under *Direkte data-API-er* i API-manualen i plattformen. For nøklene til å slå sammen datasett, se [Relasjoner mellom API-endepunkter](https://docs.cerrix.com/cerrix-functionalities/admin-settings/api-documentation/api-endpoint-relationships). ## Kontrolltestingsendepunkter for automatiserte Testplaner Utover rapporteringsdatasettene støtter Effektivitetstesting-API-et automatisering av trinn i en Testplan-Workflow fra et eksternt system: * **Generer prøver** for en Testplan, og **last opp kildedokumenter** for manuell prøvetaking. * **Hent prøver** returnerer prøvene og testtrinnene i en Testplan, inkludert dokument-GUID og navnet til hver bevisfil — også for bevis som stammer fra Kontroll-utførelsesoppgaver i utførelsesbasert testing — og dedikerte endepunkter returnerer bevisfilen til en prøve eller et testtrinn. * **Send inn sluttresultatet** og kommentaren til en Testplan som har status *Testing – venter på konklusjon*; Testplanen går deretter videre til neste Workflow-trinn. Endepunktet følger applikasjonens tillatelsesmodell: bare den tildelte kontrolltesteren eller en bruker med rollen som kontrolladministrator kan sende inn en poengsum (begrensede administratorer kun for sine egne organisasjoner). Testplaner for kontroller som ikke fant sted følger en annen Workflow og dekkes ikke av dette endepunktet. Alle Effektivitetstesting-endepunkter, deres parametere og responsfelter er beskrevet i API-manualen i plattformen. --- # 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-documentation.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.