Jobindsats har slukket API v2 – gamle rapporter svarer ikke længere

Jobindsats meddeler, at API v2 blev lukket den 30. september 2026. Kald til den gamle version besvares ikke længere. Integrationer, scripts og rapporter, som stadig bruger v2, skal derfor opdateres til v3 for at hente data igen.

For udviklere og analytikere i blandt andet kommuner og a-kasser er ændringen konkret: Den gamle API-adresse skal udskiftes, og forespørgslerne skal bygges efter v3’s krav. Jobindsats’ vejledning til v3 beskriver særskilte kald til emner, målinger, specifikationer og data samt krav til format, parametre og adgangstoken.

Fire kald fører fra emne til data

Overgangen begynder med at finde den rigtige måling, før selve dataudtrækket kan sammensættes. V3 bruger forskellige adresser til at finde emner, hente en oversigt over målinger, læse en bestemt målings opbygning og hente dens tal. Det gør målingens id og dens specifikationer til forbindelsen mellem de enkelte kald.

• Emner: /v3/subjects?format=json giver emner og underemner i databanken. Hvert emne har et subject_id, som kan bruges til at afgrænse oversigten over målinger.
• Målinger: /v3/tables?format=json giver oplysninger om målingerne, blandt andet deres id, tilgængelige perioder, opdatering og mulige fordelinger. Kaldet kan afgrænses med subject_id, hvis integrationen kun skal bruge målinger under et bestemt emne.
• Specifikation: /v3/table/<table_id>?format=json beskriver en valgt måling. Svaret indeholder blandt andet målingsvariable, dimensioner, hierarkier og periodetyper, som er nødvendige for at bygge datakaldet.
• Data: /v3/data/<table_id> henter de faktiske tal. Her skal forespørgslen også angive de relevante valg af målingsvariable, område, periode og format.

Et table_id er målingens id fra oversigten, ikke navnet på et emne. I en eksisterende rapport er det derfor ikke nok at ændre versionsnummeret i adressen: Det konkrete datakald skal svare til de muligheder og krav, som specifikationen for den valgte måling viser.

Datakaldet kræver præcise valg

Et dataudtræk skal angive, hvilke målingsvariable der ønskes. De tilhørende id’er findes i specifikationens felter for mgroups og measures og sættes i parametre, der begynder med mgroup. Hvis alle målingsvariable for en måling skal med, beskriver vejledningen også formen mgroup.*=*. Valget bør afspejle de tal, den eksisterende rapport faktisk bruger.

Område og periode skal ligeledes fremgå af forespørgslen. Perioder angives med en period-parameter, hvor den valgte periodetype og enten bestemte perioder eller et antal seneste perioder indgår. En stjerne kan ikke bruges til at hente samtlige perioder. En rapport med et fast historisk udsnit og en rapport, der altid skal vise de seneste perioder, kræver derfor forskellige periodevalg.

Fordelinger som kommune, region, køn og alder vælges gennem målingens hierarkier. Hierarkiets id og de mulige udfald hentes fra specifikationen; de bør ikke gættes ud fra en tidligere forespørgsel. Nogle dimensioner er obligatoriske for en bestemt måling. Hvis en obligatorisk dimension samtidig er skjult for valg af enkelte udfald, beskriver vejledningen, hvordan alle dens udfald angives i datakaldet.

Format og store bogstaver kan stoppe et ellers rigtigt kald

V3 kan levere JSON eller CSV, men formatet skal angives i kaldet. Parametrene format=json og format=csv vælger hver sit svarformat. En integration, som forventer CSV til et regneark eller JSON til videre behandling, skal derfor både sende den rigtige formatparameter og kunne læse det svar, den har bedt om.

API’et skelner mellem store og små bogstaver. Adresser, parameternavne og id’er skal følge den skrivemåde, som dokumentationen og specifikationen viser; en ændret bogstavstørrelse kan få kaldet til at fejle. Vejledningen angiver desuden, at kald kan sendes som GET eller POST, og at hver HTTP-forespørgsel skal have en Authorization-header med et gyldigt Bearer-token.

Hvis et v3-kald mangler en nødvendig parameter eller indeholder et forkert valg, kan API’et returnere en fejlbesked, der peger på problemet. Klienten skal muligvis sættes op til at vise selve fejlbeskeden. Den forskel er nyttig i fejlsøgningen: Et ubesvaret v2-kald skyldes lukningen, mens et afvist v3-kald også kan skyldes målingens krav eller forespørgslens syntaks.

Eksisterende rapporter skal gennemgå hele forbindelsen

Skiftet berører også løsninger, hvor API-kaldet ligger bag et rapportværktøj. TARGIT beskrev i sin omtale af sit Jobindsats-plugin til v3 i juni 2026, hvordan en datakilde konfigureres med token samt valg af emne, måling, målingsvariable, dimensioner og perioder. Omtalen blev skrevet før lukningen og fastslår derfor ikke, om et bestemt plugin eller en bestemt rapport siden er blevet opdateret.

En migrationskontrol bør følge den samme kæde fra rapportens datakilde til det endelige udtræk: Find først den gemte API-adresse, identificér målingen via emner og målingsoversigten, læs dens aktuelle specifikation, og byg derefter datakaldet med de nødvendige valg. Afprøv kaldet med samme format og adgangstoken som den planlagte integration. Jobindsats stiller også en API-konsol til rådighed, hvor kald kan sammensættes og afprøves, før de bruges i egen kode.

For rapporter, der fortsat peger på v2, kommer der ikke nye svar fra den gamle version. Deres videre drift afhænger af, at både kaldet og de valg, rapporten bygger sine tal på, passer til v3.

Læs også:

• Docker eller Podman: Rootless-sikkerhed har en målbar pris
• Registrér NIS 2 på Virk – nye omfattede virksomheder har kun to uger
• AI kan løfte opgaven uden at forbedre læringen, advarer to EU-rapporter