Reserved Testdata‑API (RT‑API)

Reserved Testdata‑API (RT‑API) gjør det mulig for konsumenter å opprette statiske testpersoner i testmiljøet til Person‑API.
Ved hjelp av API‑et kan en konsument reservere identifikasjonsnumre (fødsels‑ eller D‑nummer) og opprette og oppdatere persondokumenter for disse reserverte personene. Når en person er opprettet eller oppdatert i RT‑API, vil det oppdaterte persondokumentet kort tid etterpå være tilgjengelig i Person‑API.

RT‑API er sikret med HelseID på samme måte som Person‑API, og bruker informasjonen i tokenet (organisasjonsnummer) til å knytte en reservert testperson til en spesifikk eier. Kun eieren av en testperson kan sende oppdateringer via RT‑API.

API‑et “simulerer” input fra Folkeregisteret/FREG til Person‑API, så datamodellen for RT‑API tilsvarer FREG‑datamodellen.

Send tilbakemeldinger og spørsmål til utvikling-persontjenesten@nhn.no

Syntetiske identifikasjonsnumre

Testpersoner får syntetiske identifikasjonsnumre (NIN‑er) for å unngå kollisjon med ekte personer i Folkeregisteret (FREG).
Konsumenten reserverer NIN‑er via ReservedNin‑API‑endepunktene. Når dette gjøres, genererer RT‑API et NIN etter følgende regler:

• Fødselsnummer (national identity number)
  • +65 legges til fødselsmåneden
• D‑nummer
  • +65 legges til fødselsmåneden
  • +4 legges til den første sifren i fødselsdagen

NIN‑generering med 2032‑metoden

RT‑API har en implementasjon for å reservere syntetiske NIN‑er generert med den nye 2032‑metoden, men denne funksjonaliteten er foreløpig deaktivert.

Når den er aktivert, vil ReservedNin‑endepunktet eksponere parameteren generate2032. Hvis generate2032 settes til true, vil det syntetiske NIN‑et bli generert med 2032‑metoden. Parameteren gender brukes ikke når 2032‑metoden benyttes.

For mer informasjon om de kommende endringene av norske identifikasjonsnumre, se New NIN from 2032.

Opprette testpersoner

Når du oppretter en testperson med POST /api/v2/testperson, må feltet erGjeldende på identifikasjonsnummer være med i forespørsel‑bodyen. OpenAPI‑spesifikasjonen markerer dette feltet som nullable, men forespørsler hvor erGjeldende utelates vil bli avvist med 400 Bad Request.

For et gjeldende identifikasjonsnummer, sett erGjeldende til true.

OpenAPI‑spesifikasjon

Se Reserved Testdata API

Versjonering

Dette API‑et bruker URL‑versjonering, der hovedversjoner som inneholder bruddende endringer får en ny URL. Et eksempel på en rute er: api/v2/{endpoint}
Hvis ingen versjon angis i URL‑en, som i api/{endpoint}, blir v2 brukt som standard (og dette er for øyeblikket den eneste tilgjengelige versjonen).

Mindre versjoner (minor) som er bakoverkompatible får ikke ny URL. For å se endringer i minor‑versjoner, se API‑changelog

For mer informasjon om Major‑Minor‑versjonering generelt, se denne siden

Endringslogg

Se Changelog

Autentisering og autorisasjon

V2 – DPoP‑token

Dette API‑et bruker HelseID for autentisering og autorisasjon. For å bruke API‑et må du ha et gyldig HelseID‑DPoP‑token med scopet
nhn:persontjenesten-reservert-testdata/tilgang-dpop. Tilgang til Reserved Testdata‑API kan forespørres i HelseID‑selvbetjeningsportalen.

For mer dokumentasjon om bruk av DPoP‑tokens, se Dokumentasjon fra HelseID