Fra Gemini til FS GraphQL API
⚠ Gemini er under avvikling. Det er ikke publisert noen samlet sluttdato for tjenesten. Avviklingen skjer endepunkt for endepunkt, ikke som én dato for hele API-et — se tabellen «Status per Gemini-modul» under for hva som gjelder din bruk. Se Sikts avviklingspraksis og avviklingsloggen. Kilder: tjenesteoversikten og OpenAPI-dokumentasjonen for Gemini.
Denne guiden hjelper deg å migrere fra Gemini til FS GraphQL API.
Listen med eksempler under er ikke komplett. Ta kontakt med fs-support@sikt.no dersom du trenger hjelp til å finne en spørring eller en mutasjon som passer ditt behov.
Status per Gemini-modul
Gemini består av tre moduler: Person, Godkjenning av utdanning og Felleskoder. De har ulik status, og du trenger bare å migrere den delen du faktisk bruker.
Statusen over er hentet fra Gemini sin egen OpenAPI-spesifikasjon, fra Sikts kundevarsel «Påminnelse om avvikling av endepunkter i Gemini etter 31.03.2026» og fra avviklingsloggen, sist verifisert 18.09.2026. Er du i tvil om et konkret endepunkt fortsatt svarer, kontakt fs-support@sikt.no.
Før du starter
Sett deg inn i disse tingene før du går videre:
- Tilgang, endepunkt og kontraktsnivå (
Feature-Flags-header): Kom i gang - Paginering: Spørringer
- Feilhåndtering i mutasjoner: Mutasjoner
- Autorisasjon (RAS): Tilgangsstyring med RAS
- Bruker du en integrasjonsplattform (Gravitee/IntArk): FS GraphQL API og IntArk
- Utforsk skjemaet selv: Introspeksjon
Kontraktsnivå i eksemplene
Hver seksjon under er merket med kontraktsnivå.
stable virker uten videre. beta og experimental er skrudd av som standard, og du må sende med headeren
{ "Feature-Flags": "beta,experimental" }
Experimental-felt kan endres eller forsvinne uten varsel — ikke bygg produksjonsintegrasjoner på dem. Trenger du et experimental-felt i produksjon, ta kontakt med fs-support@sikt.no og be om at det løftes til beta.
Kontraktsnivået til en spørring og kontraktsnivået til feltene du velger ut er to forskjellige ting. En experimental-spørring kan returnere en type som har beta-felt, og da må headeren dekke begge. Se GET /utdanningsplanelementer for et konkret eksempel.
Institusjonsnummer i eksemplene
Alle eksemplene under bruker eierOrganisasjonskode: "1234". Bytt ut «1234» med institusjonsnummeret til ditt lærested.
I Gemini heter dette eierinstitusjonsnummer. I FS GraphQL API heter det eierOrganisasjonskode, og det er den samme verdien — «institusjonsnummer» er bare omdøpt til «organisasjonskode». Hver institusjon har sin egen FS-database, og feltet styrer hvilken database spørringen leser fra. Dette er derfor et påkrevd felt i de fleste filtrene.
IDer: er de samme som i Gemini?
Ja, formatet er det samme — men behandle dem fortsatt som ugjennomsiktige.
Gemini bruker allerede de samme base64-kodede ID-verdiene som FS GraphQL API. Et landId i Gemini kan brukes direkte som id på Land i GraphQL, et institusjonId som id på Organisasjon, og så videre. Dette er verifisert for Land, Organisasjon, Tidsenhet og Vektingstype.
Forretningsnøklene er også de samme i begge API-ene: organisasjonskode (institusjonsnummer), landnummer, emnekode + versjonskode, personløpenummer og så videre. Det er disse du bør bruke hvis du skal koble sammen data du allerede har lagret fra Gemini med data fra GraphQL.
Selve ID-strengen skal du derimot ikke tolke. Du kan riktignok base64-dekode den, men innholdet og formatet er en intern implementasjonsdetalj som kan endres uten varsel — ikke konstruer dem selv, og ikke parse dem for å hente ut forretningsnøkler. Bruk dem kun slik du fikk dem.
Er du usikker på om en ID du har lagret fra Gemini fortsatt peker på det du tror, kan du slå den opp direkte. node er en generisk spørring som tar en hvilken som helst ID og returnerer objektet den peker på. __typename er GraphQL sin innebygde måte å spørre «hvilken type er dette egentlig»:
Kontraktsnivå: stable
query SjekkId {
node(id: "NjI6MA") {
__typename
id
... on Land {
landnummer
landkodeAlfa3
navnAlleSprak {
nb
}
}
}
}
Eksempel på svar:
{
"data": {
"node": {
"__typename": "Land",
"id": "NjI6MA",
"landnummer": "0",
"landkodeAlfa3": "NOR",
"navnAlleSprak": {
"nb": "Norge"
}
}
}
}
... on Land { … } kalles et inline fragment. Fordi node kan returnere hvilken som helst type, må du si eksplisitt hvilke felt du vil ha for hvilken type. Du treffer samme konstruksjon igjen i feilhåndtering for mutasjoner lenger ned.
Har du ingen ID, men bare en forretningsnøkkel, finnes det egne oppslagsspørringer. På stabilt nivå blant annet personProfilerGittFodselsnumre, personProfilerGittPersonlopenumre, personProfilerGittFeideBrukere, personProfilerGittAnsattnumre og studenterGittStudentnumre. For land og organisasjoner: landGittLandnumre, landGittLandkodeAlfa3 og organisasjonerGittOrganisasjonskoder (de to siste på experimental-nivå).
Tilgang: hvilken RAS-rolle trenger du?
Gemini og FS GraphQL API bruker samme tilgangsmodell — Oracle RAS, med roller du bestiller sammen med API-brukeren din. Forskjellen ligger i granulariteten: Gemini styrer i praksis per endepunkt, FS GraphQL API styrer per tabell og per kolonne. Ett gammelt Gemini-kall krever derfor ofte flere roller i GraphQL.
Hvilke roller du trenger avhenger av hvilken Gemini-modul du migrerer:
Felleskoder: ingen egen rolle kreves. Alle felleskodene i denne guiden — emner, emnekategorier,
institusjoner, land, organisasjonsenheter, termintyper, tidsenheter, utdanningsplanelementer,
utdanningsplanelementtyper og vektingstyper — dekkes av STUDIEELEMENTER_LES1, som tildeles
automatisk. Du trenger ikke bestille noe ekstra for denne delen. Se
Grunnleggende tilgang.
eierOrganisasjonskode avgrenser fortsatt hvilket læresteds data du får.
Person, lesing: PERSONDATA_LES1 er minimum. Den gir grunnleggende personopplysninger om alle
personer — navn, fødselsdato, kjønn, målform, e-post, telefon og folkeregistrert adresse. Skjermede
felt krever én rolle hver: PERSONDATA_LES2 (fødselsnummer), PERSONDATA_LES3 (ansattnummer),
PERSONDATA_LES4 (bankkontonummer), PERSON_PASS_LES1 (pass),
PERSON_STATSBORGERSKAP_LES1 (statsborgerskap), STUDENTDATA_LES1 (student-feltet) og
FAGPERSONDATA_LES1 (fagperson-feltet). Feltmappingen under
GET /personer merker hvilket felt som krever hva. Se
Tilgang til persondata,
Tilgang til studentdata
og Tilgang til fagpersondata
for bestillingsrutine.
En rolle kan avgrense hvilke personer du ser, ikke bare hvilke felt. PERSONDATA_LES1 gir alle
personer. STUDENTDATA_LES1 gir bare personer som er studenter, og FAGPERSONDATA_LES2 bare
personer som er fagpersoner. Har du bare STUDENTDATA_LES1, returnerer personProfiler kun
studenter — der Gemini sitt GET /personer med tilsvarende tilgang returnerte alle. Sjekk antall
treff mot forventet volum hvis et søk virker for tynt.
Person, oppretting: rollen følger personrollen du oppretter. opprettFagpersonerGittFodselsnumre
krever PERSONDATA_SKRIV1 og FAGPERSONDATA_SKRIV1; opprettFagpersonerGittPass krever i tillegg
PERSON_PASS_SKRIV1. opprettStudenter krever STUDENT_OPPRETT, som er satt sammen nettopp for
dette formålet — se
Tilgang til å opprette studenter.
For de to experimental-mutasjonene (opprettAdministrativtAnsatteGittFodselsnummer og
opprettPersonProfilerUtenFodselsnummer) er rollepakken ikke publisert ennå — beskriv bruken din
ved bestilling, så setter vi den opp.
Godkjenning av utdanning: rollene finnes allerede. Skal du lese eksternresultater på
experimental-nivå, trenger du STUDENT_GODKJENNING_LES1. Bestillinger av resultatutveksling ligger
bak STUDENT_GODKJENNING_LES2. Rollene står i tabellen under
Tilgang til studentdata.
Merk at anbefalingen vår fortsatt er å bli i Gemini for denne modulen inntil videre — se
Godkjenning av utdanning.
Mangler du en rolle, får du ingen feilmelding når du leser. Spørringen returnerer HTTP 200 som
vanlig. Du får enten null på feltet du ikke har tilgang til, eller — og dette er lettere å overse
— færre rader, fordi personene du ikke har tilgang til rett og slett ikke er der. Sjekk at antall
treff stemmer med det du forventer før du setter integrasjonen i produksjon. Skriveoperasjoner
oppfører seg annerledes: en opprett…-mutasjon uten nødvendig skriverolle feiler, den går ikke
stille gjennom.
Finner du ingen rolle som dekker behovet ditt, ta kontakt med fs-support@sikt.no og beskriv det — nye roller opprettes ved behov.
Konstruer en relevant GraphQL-spørring for henting av data
Felleskoder-modulen i Gemini inneholder primært grunnlagsdata som er ment brukt sammen med Person- og Godkjenning-modulene. Anbefalt bruk i Gemini er at du først laster ned og cacher disse grunnlagsdataene, slik at de er tilgjengelige når du gjør kall mot de andre modulene.
I GraphQL trenger du som regel ikke dette mønsteret. Du kan hente grunnlagsdataene i kontekst av hovedspørringen, i samme kall. En GraphQL-spørring kan følge relasjoner mellom objekter — der du i Gemini måtte gjøre ett kall for å hente en person og et annet for å slå opp hva landId betyr, kan du i GraphQL be om begge deler på én gang:
query PersonMedPassland {
personProfilerGittFodselsnumre(
eierOrganisasjonskode: "1234"
fodselsnumre: ["15611012370"]
) {
id
navn {
fornavn
etternavn
}
pass {
passnummer
land {
landkodeAlfa3
navnAlleSprak {
nb
}
}
}
}
}
pass er en liste — en person kan ha registrert flere pass i FS. Her hentes landnavnet i samme kall som personen, uten et separat oppslag mot en cachet kodetabell. (Kontraktsnivå: stable.)
For de felleskodene som fortsatt har en GraphQL-motpart tilbyr vi likevel tilsvarende spørringer, slik at klienter som ønsker det kan gå gradvis over.
Les mer om spørringer i FS GraphQL API her: Spørringer
Paginering
FS GraphQL API bruker cursor-basert paginering, på samme måte som Gemini. Der Gemini bruker after og pageSize, bruker GraphQL after og first.
Svaret kommer i en edges/node-struktur med et pageInfo-objekt. Du henter neste side ved å sende pageInfo.endCursor inn som after i neste kall, så lenge pageInfo.hasNextPage er true.
Les mer her: Paginering
Person-modulen
De tre operasjonene i Person-modulen er merket deprecated i Gemini og har støttefrist (End of Service) 31.03.2027. Dette er den delen av Gemini du bør migrere først.
GET /personer og GET /personer/:personId
Kontraktsnivå: stable
GET /personer søker etter personer med et sett query-parametre. I FS GraphQL API bruker du personProfiler for søk, eller en av …Gitt…-spørringene for direkte oppslag når du allerede har en identifikator.
GET /personer/:personId tilsvarer node(id:) med et inline fragment på PersonProfil, eller personProfilerGittPersonlopenumre hvis du har personløpenummeret.
Slik mapper søkeparametrene:
Slik mapper feltene i svaret:
Eksempel — søk etter personer (tilsvarer GET /personer?eierinstitusjonsnummer=1234&etternavn=Nordmann):
query SokPersoner {
personProfiler(
filter: {
eierOrganisasjonskode: "1234"
freeText: "Nordmann"
}
first: 2
) {
edges {
node {
id
personlopenummer
navn {
fornavn
etternavn
}
fodselsdato
kjonn
maalform
institusjonsEpost
privatEpost
mobilTelefon {
landnummer
nummer
}
folkeregistrertAdresse {
co
gate
postnummerOgSted
land
}
student {
studentnummer
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"personProfiler": {
"edges": [
{
"node": {
"id": "NzY6MTIzNCwxMDAw",
"personlopenummer": "1000",
"navn": {
"fornavn": "Ola",
"etternavn": "Nordmann"
},
"fodselsdato": "1990-11-15",
"kjonn": "MANN",
"maalform": "NB",
"institusjonsEpost": "ola.nordmann@institusjon.no",
"privatEpost": "ola.nordmann@epost.no",
"mobilTelefon": {
"landnummer": "+47",
"nummer": "11223344"
},
"folkeregistrertAdresse": {
"co": null,
"gate": "Gate 1",
"postnummerOgSted": "9876 Sildefjord",
"land": "Norge"
},
"student": {
"studentnummer": "201"
}
}
},
{
"node": {
"id": "NzY6MTIzNCwxMDAx",
"personlopenummer": "1001",
"navn": {
"fornavn": "Kari",
"etternavn": "Nordmann"
},
"fodselsdato": "1992-03-04",
"kjonn": "KVINNE",
"maalform": "NN",
"institusjonsEpost": "kari.nordmann@institusjon.no",
"privatEpost": null,
"mobilTelefon": null,
"folkeregistrertAdresse": {
"co": null,
"gate": "Gate 2",
"postnummerOgSted": "5020 Bergen",
"land": "Norge"
},
"student": null
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WzEyMzQsIjEwMDEiXQ"
}
}
}
}
Eksempel — oppslag på én person (tilsvarer GET /personer/:personId):
query HentPerson {
node(id: "NzY6MTIzNCwxMDAw") {
__typename
... on PersonProfil {
id
personlopenummer
navn {
fornavn
etternavn
}
fodselsnummer
fodselsnummertype
}
}
}
Semantiske forskjeller du bør merke deg:
- Tilgangsstyringen er lik i prinsipp, men rollene sjekkes per felt. I Gemini står RAS-rollene beskrevet i endepunktdokumentasjonen (
PERSONDATA_LES1som minimum,PERSONDATA_LES2for fødselsnummer, og så videre). De samme rollene gjelder i FS GraphQL API. Mangler du en rolle, får du ikke en 403 på hele kallet — du fårnullpå det feltet du ikke har tilgang til. Se Tilgangsstyring med RAS. - Fritekstsøket er bredere.
filter.freeTextsøker i fornavn, etternavn, fødselsnummer, mobilnummer og studentnummer samtidig. Trenger du å søke kun på etternavn, må du filtrere videre på klientsiden. - Avdøde personer utelates som standard. Gemini har ikke dette skillet.
POST /personer
Det finnes ingen enkelt mutasjon som tilsvarer POST /personer direkte — fordi FS ikke har et konsept for en «ren» person uten rolle.
POST /personer i Gemini oppretter en personoppføring i FS. I FS sin datamodell blir en person derimot alltid opprettet i en rolle — som fagperson, administrativt ansatt eller student. Det finnes ingen generell «bare opprett en person»-mutasjon i FS GraphQL API for noen med fødselsnummer, fordi det ikke finnes noe tilsvarende bare-person-konsept å opprette i FS selv. Hvilken mutasjon du bruker avhenger derfor av hvilken rolle personen skal ha:
Den eneste mutasjonen som oppretter en personprofil uten samtidig å tildele en rolle, er opprettPersonProfilerUtenFodselsnummer — og den er forbeholdt personer FS ikke har et fødselsnummer for ennå. Har personen fødselsnummer, må du velge rolle. Kjenner du en reell bruksmåte for POST /personer i Gemini som ikke naturlig faller inn under noen av rollene over, ta kontakt med fs-support@sikt.no og beskriv den — det er mer sannsynlig et spørsmål om hvilken rolle som passer enn et hull i API-et.
Eksempel — opprett fagperson gitt fødselsnummer (Kontraktsnivå: stable):
mutation OpprettFagperson {
opprettFagpersonerGittFodselsnumre(
input: [
{
eierOrganisasjonskode: "1234"
fodselsnummer: "15611012370"
fornavn: "Ola"
etternavn: "Nordmann"
privatEpost: "ola.nordmann@epost.no"
maalform: NB
mobilTelefon: { landnummer: "+47", nummer: "11223344" }
}
]
) {
result {
personProfil {
id
personlopenummer
navn {
fornavn
etternavn
}
}
}
errors {
... on Error {
message
path
}
}
}
}
errors er en union-type — en liste over ulike feiltyper som alle implementerer grensesnittet Error. Du kan derfor ikke skrive errors { message } direkte; du må selektere gjennom et inline fragment. ... on Error { message path } gir deg de to feltene alle feiltyper har. Vil du skille på feiltype, legger du til flere fragmenter, for eksempel ... on UgyldigInput { message }.
Semantisk forskjell: Gemini rapporterer feil med HTTP-statuskoder og Problem Details (RFC 7807). FS GraphQL API returnerer HTTP 200 også når en mutasjon feiler funksjonelt, og legger feilen i errors-feltet i payloaden. Sjekker du bare HTTP-status, vil du tro at kallet gikk bra. Les mer i Mutasjoner.
Godkjenning av utdanning
Denne modulen dekker utdanningsplaner, emnefritak, eksternresultater, resultatutveksling og utvekslingsopphold, alle som subressurser under /personer/:personId/.
Modulen er ikke varslet avviklet, og det er ikke publisert noen sluttdato. Operasjonene er ikke merket deprecated i Gemini sin OpenAPI-spesifikasjon.
FS GraphQL API har foreløpig bare delvis dekning av dette domenet:
- Lesing av eksternresultater og elementer i utdanningsplaner finnes på experimental-nivå (
Eksternresultat,EksternresultatIUtdanningsplan), og experimental-nivå er ikke ment for produksjonsbruk. - Emnefritak har ingen motpart i FS GraphQL API i dag.
- Skriveoperasjonene i denne modulen — legge til og slette emner og eksternresultater i utdanningsplaner, registrere emnefritak, registrere resultatutveksling — har ingen tilsvarende mutasjoner i FS GraphQL API i dag.
Vår anbefaling: fortsett å bruke Gemini for denne modulen inntil videre. Vi varsler ikke avvikling av et API før tilsvarende funksjonalitet er på plass i FS GraphQL API.
Planlegger du en større omlegging og vil vite hvor dette arbeidet står, ta kontakt med fs-support@sikt.no.
Felleskoder som fortsatt finnes i Gemini
Disse seks endepunktene er fortsatt en del av Gemini og er ikke varslet avviklet. De er grunnlagsdata for Godkjenning-modulen. Fem av dem har ingen tilsvarende spørringer i FS GraphQL API i dag — fortsett å bruke Gemini for disse, og ta kontakt med fs-support@sikt.no hvis du trenger dem i FS GraphQL API:
GET /emnevalgstatuserGET /eksternresultatperioderGET /eksternresultatbeskrivelsesmodellerGET /eksternresultatregistreringskilderGET /eksternresultatkategorier
Det sjette, GET /emnekategorier, har allerede en erstatning — du kan migrere den allerede nå:
GET /emnekategorier
Kontraktsnivå: stable · I Gemini: fortsatt tilgjengelig, ikke varslet avviklet
emnekategoriId i Gemini er den samme verdien som id i GraphQL.
query Emnekategorier {
emnekategorier(filter: { eierOrganisasjonskode: "1234" }) {
edges {
node {
id
kode
erAktiv
navnAlleSprak {
nb
nn
en
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"emnekategorier": {
"edges": [
{
"node": {
"id": "MjE6MTIzNCwx",
"kode": "1",
"erAktiv": true,
"navnAlleSprak": {
"nb": "1. årskurs",
"nn": null,
"en": null
}
}
},
{
"node": {
"id": "MjE6MTIzNCwxQVZE",
"kode": "1AVD",
"erAktiv": true,
"navnAlleSprak": {
"nb": "1. avdeling",
"nn": null,
"en": null
}
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "…"
}
}
}
}
Feltmapping: emnekategoriId → id, kode → kode, navn.nob/navn.nno/navn.eng → navnAlleSprak.nb/.nn/.en, aktiv → erAktiv. Feltene nob, nno og eng finnes også på EmnekategorinavnAlleSprak, men er @deprecated med utløpt fjerningsdato — bruk nb, nn og en.
Felleskoder som er tatt ut av Gemini
Sikt varslet i februar 2025 avvikling av disse ni endepunktene (åtte av dem etter 31.03.2026, /emner opprinnelig etter 20.03.2025), og de er ikke lenger dokumentert i Gemini sin OpenAPI-spesifikasjon. Eksemplene viser hvordan du henter de samme dataene fra FS GraphQL API.
Merk at GraphQL gir stor fleksibilitet i hvilke data du kan hente. Bruk eksemplene som utgangspunkt, og konstruer en spørring skreddersydd for ditt behov. Svareksemplene er forkortet til noen få rader.
GET /emner
Kontraktsnivå: stable · I Gemini: opprinnelig varslet avviklet etter 20.03.2025 (Sikts varsel 10.02.2025), men fortsatt nevnt i et senere kundevarsel om 31.03.2026-batchen. Uansett hvilken dato som er korrekt: endepunktet er ikke lenger dokumentert i Gemini sin OpenAPI-spesifikasjon
Spørringen heter emnerV2. Den eldre emner-spørringen er @deprecated med utløpt fjerningsdato (31.03.2026) og skal ikke brukes i nye integrasjoner.
Et emne identifiseres av emnekode og versjonskode sammen — samme emnekode kan finnes i flere versjoner. Ta med begge hvis du skal koble mot data du har lagret fra Gemini.
query Emner {
emnerV2(
filter: { eierOrganisasjonskode: "1234" }
first: 10
) {
edges {
node {
id
kode
versjonskode
navnAlleSprak {
nb
nn
en
se
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"emnerV2": {
"edges": [
{
"node": {
"id": "MjA6MTIzNCwxNTAsMUJBLTExMSwx",
"kode": "1BA-111",
"versjonskode": "1",
"navnAlleSprak": {
"nb": "Bevegelseslære",
"nn": "Bevegingslære",
"en": "The Science of Movement",
"se": null
}
}
},
{
"node": {
"id": "MjA6MTIzNCwxNTAsMUJBLTEyMSwx",
"kode": "1BA-121",
"versjonskode": "1",
"navnAlleSprak": {
"nb": "Idrett og samfunn",
"nn": null,
"en": null,
"se": null
}
}
},
{
"node": {
"id": "MjA6MTIzNCwxNTAsMUJBLTEyMSwy",
"kode": "1BA-121",
"versjonskode": "2",
"navnAlleSprak": {
"nb": "Idrett og samfunn",
"nn": null,
"en": null,
"se": null
}
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WzEyMzQsMTUwLCIxQkEtMTIxIiwiMiJd"
}
}
}
}
GET /institusjoner
Kontraktsnivå: experimental — krever headeren Feature-Flags: experimental. I Gemini: varslet avviklet etter 31.03.2026.
Objektet Institusjon heter Organisasjon i FS GraphQL API, og feltet institusjonsnummer heter organisasjonskode.
Feltet Organisasjon.navn er @deprecated med utløpt fjerningsdato (31.03.2026). Bruk navnAlleSprak i stedet — det har nøyaktig samme innhold.
query Organisasjoner {
organisasjoner(first: 10) {
edges {
node {
id
organisasjonskode
forkortelse
navnAlleSprak {
nb
nn
en
se
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"organisasjoner": {
"edges": [
{
"node": {
"id": "NDY6MTUw",
"organisasjonskode": "150",
"forkortelse": "NIH",
"navnAlleSprak": {
"nb": "Norges idrettshøgskole",
"nn": null,
"en": "Norwegian School of Sport Sciences",
"se": null
}
}
},
{
"node": {
"id": "NDY6MTg0",
"organisasjonskode": "184",
"forkortelse": "UiB",
"navnAlleSprak": {
"nb": "Universitetet i Bergen",
"nn": "Universitetet i Bergen",
"en": "University of Bergen",
"se": null
}
}
},
{
"node": {
"id": "NDY6MTg2",
"organisasjonskode": "186",
"forkortelse": "UiT",
"navnAlleSprak": {
"nb": "UiT Norges arktiske universitet",
"nn": "UiT Noregs arktiske universitet",
"en": "UiT The Arctic University of Norway",
"se": "Romssa universitehta"
}
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WzE4Nl0"
}
}
}
}
Har du organisasjonskodene fra før, kan du slå opp direkte med organisasjonerGittOrganisasjonskoder(organisasjonskoder: ["184", "186"]) i stedet for å paginere gjennom hele listen. Også denne er på experimental-nivå.
GET /land
Kontraktsnivå: stable · I Gemini: varslet avviklet etter 31.03.2026
landnummer er SSB-landnummeret og er den forretningsnøkkelen du mest sannsynlig har lagret fra Gemini.
query Land {
land(first: 10) {
edges {
node {
id
landnummer
landkodeAlfa2
landkodeAlfa3
navnAlleSprak {
nb
nn
en
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"land": {
"edges": [
{
"node": {
"id": "NjI6MA",
"landnummer": "0",
"landkodeAlfa2": "NO",
"landkodeAlfa3": "NOR",
"navnAlleSprak": {
"nb": "Norge",
"nn": "Noreg",
"en": "Norway"
}
}
},
{
"node": {
"id": "NjI6MTAx",
"landnummer": "101",
"landkodeAlfa2": "DK",
"landkodeAlfa3": "DNK",
"navnAlleSprak": {
"nb": "Danmark",
"nn": null,
"en": "Denmark"
}
}
},
{
"node": {
"id": "NjI6MTA2",
"landnummer": "106",
"landkodeAlfa2": "SE",
"landkodeAlfa3": "SWE",
"navnAlleSprak": {
"nb": "Sverige",
"nn": null,
"en": "Sweden"
}
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WzEwNl0"
}
}
}
}
Land har ikke et se-felt (nordsamisk) i navnAlleSprak, i motsetning til Organisasjon og Emne.
Har du landnumre eller ISO-3166-Alpha3-koder fra før, kan du slå opp direkte med landGittLandnumre eller landGittLandkodeAlfa3. Begge er på experimental-nivå.
GET /organisasjonsenheter
Kontraktsnivå: stable · I Gemini: varslet avviklet etter 31.03.2026
En organisasjonsenhet identifiseres i FS av en sammensatt stedkode: organisasjonskode, fakultets-/avdelingsnummer, instituttnummer og gruppenummer. Ta med alle fire hvis du skal koble mot data du har lagret fra Gemini.
Semantisk forskjell: filteret returnerer som standard bare aktive enheter (erAktiv: [true]). Gemini gjør ikke dette skillet. Vil du ha alle, sett erAktiv: [true, false].
query Organisasjonsenheter {
organisasjonsenheter(
filter: { eierOrganisasjonskode: "1234" }
first: 10
) {
edges {
node {
id
organisasjon {
organisasjonskode
}
fakultet {
fakultetsnummer
}
instituttnummer
gruppenummer
forkortelse
navnAlleSprak {
nb
nn
en
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"organisasjonsenheter": {
"edges": [
{
"node": {
"id": "Nzk6MTIzNCwxODQsMCwwLDA",
"organisasjon": {
"organisasjonskode": "184"
},
"fakultet": null,
"instituttnummer": "0",
"gruppenummer": "0",
"forkortelse": "UiB",
"navnAlleSprak": {
"nb": "Universitetet i Bergen",
"nn": "Universitetet i Bergen",
"en": "University of Bergen"
}
}
},
{
"node": {
"id": "Nzk6MTIzNCwxODQsMSwwLDA",
"organisasjon": {
"organisasjonskode": "184"
},
"fakultet": {
"fakultetsnummer": "1"
},
"instituttnummer": "0",
"gruppenummer": "0",
"forkortelse": "HF",
"navnAlleSprak": {
"nb": "Det historisk-filosofiske fakultet, UiB",
"nn": "Det historisk-filosofiske fakultetet, UiB",
"en": null
}
}
},
{
"node": {
"id": "Nzk6MTIzNCwxODQsMiwwLDA",
"organisasjon": {
"organisasjonskode": "184"
},
"fakultet": {
"fakultetsnummer": "2"
},
"instituttnummer": "0",
"gruppenummer": "0",
"forkortelse": "MN",
"navnAlleSprak": {
"nb": "Det matematisk-naturvitenskapelige fakultet, UiB",
"nn": "Det matematisk-naturvitskapelege fakultetet, UiB",
"en": null
}
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WzEyMzQsMTg0LDIsMCwwXQ"
}
}
}
}
GET /termintyper
Kontraktsnivå: beta — krever headeren Feature-Flags: beta. I Gemini: varslet avviklet etter 31.03.2026.
Objektet Termintype heter Terminbetegnelse i FS GraphQL API. kode tilsvarer terminkoden i FS.
query Terminbetegnelser {
terminbetegnelser(
filter: { eierOrganisasjonskode: "1234" }
first: 10
) {
edges {
node {
id
kode
navnAlleSprak {
nb
nn
en
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"terminbetegnelser": {
"edges": [
{
"node": {
"id": "MTE3OjEyMzQsSMOYU1Q",
"kode": "HØST",
"navnAlleSprak": {
"nb": "Høst",
"nn": "Haust",
"en": "Autumn"
}
}
},
{
"node": {
"id": "MTE3OjEyMzQsVsOFUg",
"kode": "VÅR",
"navnAlleSprak": {
"nb": "Vår",
"nn": "Vår",
"en": "Spring"
}
}
},
{
"node": {
"id": "MTE3OjEyMzQsU09N",
"kode": "SOM",
"navnAlleSprak": {
"nb": "Sommer",
"nn": "Sommar",
"en": "Summer"
}
}
}
],
"pageInfo": {
"hasNextPage": false,
"endCursor": "WzEyMzQsIlNPTSJd"
}
}
}
}
GET /tidsenheter
Kontraktsnivå: experimental — krever headeren Feature-Flags: experimental. I Gemini: varslet avviklet etter 31.03.2026.
query Tidsenheter {
tidsenheter(first: 10) {
edges {
node {
id
kode
navnAlleSprak {
nb
nn
en
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"tidsenheter": {
"edges": [
{
"node": {
"id": "MTE4OkRBR0VS",
"kode": "DAGER",
"navnAlleSprak": {
"nb": "Dager",
"nn": "Dagar",
"en": "Days"
}
}
},
{
"node": {
"id": "MTE4OlNFTUVTVFJF",
"kode": "SEMESTRE",
"navnAlleSprak": {
"nb": "Semestre",
"nn": "Semester",
"en": "Semesters"
}
}
},
{
"node": {
"id": "MTE4OlVLRVI",
"kode": "UKER",
"navnAlleSprak": {
"nb": "Uker",
"nn": "Veker",
"en": "Weeks"
}
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WyJVS0VSIl0"
}
}
}
}
Feltene nob, nno og eng på TidsenhetNavnAlleSprak er @deprecated med utløpt fjerningsdato. Bruk nb, nn og en.
GET /utdanningsplanelementtyper
Kontraktsnivå: experimental — krever headeren Feature-Flags: experimental. I Gemini: varslet avviklet etter 31.03.2026.
Elementtypen sier hva slags utdanningsplanelement det er snakk om — hvert element i utdanningsplanelementer peker på én type. I motsetning til de andre felleskodene har denne typen ikke et flerspråklig navn.
query Utdanningsplanelementtyper {
utdanningsplanelementtyper(
filter: { eierOrganisasjonskode: "1234" }
) {
id
navn
felleskode
}
}
Eksempel på svar (forkortet — den faktiske id-verdien er utelatt her siden vi ikke har verifisert den nøyaktige kodingen for denne typen; den følger samme base64-mønster som de andre eksemplene):
{
"data": {
"utdanningsplanelementtyper": [
{
"id": "…",
"navn": "Emne",
"felleskode": true
},
{
"id": "…",
"navn": "Artikkel",
"felleskode": false
}
]
}
}
felleskode sier om koden er en felles FS-kode som gjelder alle læresteder (true), eller en kode lærestedet har definert selv (false). Spørringen returnerer ikke en edges/node-struktur med paginering, siden hele listen normalt er kort nok til å hentes i ett kall.
GET /utdanningsplanelementer
Kontraktsnivå: experimental for spørringen — men se advarselen under. I Gemini: varslet avviklet etter 31.03.2026.
Dette eksempelet trenger headeren Feature-Flags: beta,experimental. Spørringen utdanningsplanelementer er experimental, mens feltet vektenheterPerSemester på Vektingstype er beta — sender du bare experimental, mangler du dette feltet på den kontrakten du ba om. Dette er et generelt mønster: sjekk kontraktsnivået på feltene i returtypen, ikke bare på selve spørringen.
Feltet Utdanningsplanelement.kode er utelatt fra eksempelet under. Verifisert direkte mot testmiljøet: feltet er mappet mot Oracle-kolonnen UTDPLANELEMTYPEKODE — koden for elementets type, ikke for elementet selv — og deles derfor av mange elementer (flere ulike elementer med helt forskjellig navn og ID hadde samme kode-verdi i testen). Elementets egen kode ligger i en annen kolonne (UTDPLANELEMKODE) som bygger node-ID-en, men som ikke er eksponert som noe felt. Skal du koble mot data fra Gemini på elementets egen kode, må du foreløpig bruke id.
query Utdanningsplanelementer {
utdanningsplanelementer(
filter: { eierOrganisasjonskode: "1234" }
first: 10
) {
edges {
node {
id
navnAlleSprak {
nb
nn
en
}
vekting {
verdi
vektingstype {
kode
navnAlleSprak {
nb
nn
en
}
vektenheterPerSemester
}
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"utdanningsplanelementer": {
"edges": [
{
"node": {
"id": "MTI3OjEyMzQsQU1ILVVUVjMw",
"navnAlleSprak": {
"nb": "Utveksling ett semester - musikkstudiet",
"nn": null,
"en": "Exchange one semester - music programme"
},
"vekting": {
"verdi": 30,
"vektingstype": {
"kode": "SP",
"navnAlleSprak": {
"nb": "Studiepoeng",
"nn": "Studiepoeng",
"en": "Credits"
},
"vektenheterPerSemester": 30
}
}
}
},
{
"node": {
"id": "MTI3OjEyMzQsQVJUSUtLRUwx",
"navnAlleSprak": {
"nb": "Artikkel",
"nn": null,
"en": null
},
"vekting": {
"verdi": 4,
"vektingstype": {
"kode": "SP",
"navnAlleSprak": {
"nb": "Studiepoeng",
"nn": "Studiepoeng",
"en": "Credits"
},
"vektenheterPerSemester": 30
}
}
}
},
{
"node": {
"id": "MTI3OjEyMzQsRk9EU0VM",
"navnAlleSprak": {
"nb": "Fødselspermisjon",
"nn": null,
"en": null
},
"vekting": null
}
}
],
"pageInfo": {
"hasNextPage": true,
"endCursor": "WzEyMzQsIkZPRFNFTCJd"
}
}
}
}
vekting kan være null for elementer som ikke har vekting, slik som permisjon. Håndter dette i klienten.
GET /vektingstyper
Kontraktsnivå: experimental — krever headeren Feature-Flags: experimental. I Gemini: varslet avviklet etter 31.03.2026.
Semantisk forskjell: spørringen returnerer som standard bare aktive vektingstyper (filter.aktiv har standardverdi [true]). Vil du ha alle, sett filter: { aktiv: [true, false] }.
query Vektingstyper {
vektingstyper(first: 10) {
edges {
node {
id
kode
erAktiv
navnAlleSprak {
nb
nn
en
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
Eksempel på svar:
{
"data": {
"vektingstyper": {
"edges": [
{
"node": {
"id": "MTM2OlNQ",
"kode": "SP",
"erAktiv": true,
"navnAlleSprak": {
"nb": "Studiepoeng",
"nn": "Poeng",
"en": "Credits"
}
}
},
{
"node": {
"id": "MTM2OkZQ",
"kode": "FP",
"erAktiv": true,
"navnAlleSprak": {
"nb": "Fagskolepoeng",
"nn": "Poeng",
"en": "Credits"
}
}
},
{
"node": {
"id": "MTM2OlZU",
"kode": "VT",
"erAktiv": true,
"navnAlleSprak": {
"nb": "Vekttall",
"nn": "Vektal",
"en": "Points"
}
}
}
],
"pageInfo": {
"hasNextPage": false,
"endCursor": "WyJWVCJd"
}
}
}
}
Feltene nob, nno og eng på VektingstypenavnAlleSprak er @deprecated med utløpt fjerningsdato. Bruk nb, nn og en.
Hva om mitt behov ikke er dekket?
Vi tilstreber å ha tilsvarende funksjonalitet på plass i FS GraphQL API før vi varsler avvikling av et gammelt API eller endepunkt. Der vi ikke er helt i mål — som for ren personoppretting uten rolle i Person-modulen, se advarselen under POST /personer — vil vi gjerne høre fra deg: ta kontakt med fs-support@sikt.no og beskriv behovet.
Gemini avvikles gradvis og over tid, etter hvert som funksjonalitet blir tilgjengelig i FS GraphQL API. Enkelte klienter må derfor bruke en kombinasjon av begge API-ene i en overgangsperiode. Dette gjelder særlig deg som bruker Godkjenning-modulen: den delen fortsetter i Gemini inntil videre, mens Person-modulen bør migreres før 31.03.2027.
Kontakt FS-support for hjelp ved behov
Kontakt fs-support@sikt.no dersom du trenger hjelp til å komme i gang, eller underveis i migreringen.