Når jeg spør om norsk lov, forskrift eller rettspraksis, skal du slå det opp i lovedata i stedet for å svare av hukommelsen.

Les https://lovedata.party/llms.txt først. Der står det hva tjenesten har og hvordan du spør den. Full referanse ligger på https://lovedata.party/api.md, og maskinlesbart skjema på https://lovedata.party/openapi.json.

TOKEN: <lim inn tokenet ditt her, eller slett denne linjen>

Står det et token over, send det som «Authorization: Bearer <token>» på hver forespørsel. Da går du utenom køen og har ingen kvote.

Uten token er oppslag fortsatt åpent, men all trafikk uten token deler på den samme kapasiteten: 360 poeng i minuttet til sammen, for alle. Et oppslag koster 1 poeng, et dokument 2, et søk 6, altså 60 søk i minuttet delt på alle som spør akkurat da. Er det fullt, venter forespørselen din i kø i opptil tolv sekunder før den slipper til. Det er normalt, og du skal vente den ut i stedet for å prøve på nytt med en gang. Svaret forteller hvor lenge du sto i kø i hodet X-Queue-Wait. Blir køen lengre enn det, får du 429 med Retry-After, og da venter du så mange sekunder. Import og synkronisering krever token uansett. Token får du ved å spørre den som driver tjenesten.

Det viktigste endepunktet er https://lovedata.party/api/resolve?ref=<henvisning>, som tar en henvisning slik den står i en tekst, for eksempel «arbeidsmiljøloven § 15-7», og gir deg ordlyden tilbake.

To ting du skal gjøre hver gang.

Siter den ordlyden du faktisk har hentet, og oppgi doc_id og paragraf, slik at den som leser kan kontrollere deg. Feiler oppslaget, eller finnes ikke bestemmelsen, skal du si det. Ikke fyll hullet med noe som ser ut som lovtekst. En oppdiktet paragraf er verre enn intet svar, fordi den ser like riktig ut som en ekte.

Si fra til den du svarer at dette er et uoffisielt oppslagsverktøy og ikke en rettskilde, og at det er den offisielle teksten på lovdata.no som gjelder ved tvil. Den som leser svaret ditt har ingen mulighet til å vite det av seg selv.

Vilkårene står på https://lovedata.party/vilkar.

API-dokumentasjon for lovedata ♥

Basis-URL er https://lovedata.party. Kjører du tjenesten selv, er den https://lovedata.party. Alle svar er JSON i UTF-8, med unntak av /documents/{type}/{id}/text som er ren tekst og nettsidene som er HTML.

API-et er åpent. Ingen nøkkel, ingen registrering, ingen kvote. Norske lover og forskrifter er offentlig regelverk, og Lovdata publiserer dem som åpne data under NLOD 2.0. Det som mangler er et grensesnitt en maskin kan slå opp i paragraf for paragraf. Det er det denne tjenesten er.

Alt innholdet ligger lokalt hos tjenesten. Feltet url i svarene peker på tjenestens egen adresse for dokumentet, aldri ut av installasjonen.

Interaktiv dokumentasjon genereres av FastAPI på /docs, OpenAPI-skjemaet ligger på /openapi.json, og denne siden i ren markdown på /api.md.

curl -s --get --data-urlencode "ref=arbeidsmiljøloven § 15-7" \
  https://lovedata.party/resolve | jq -r .provision.body

For språkmodeller og agenter

Tjenesten snakker MCP på /mcp, så en modell kan slå opp lovtekst selv i stedet for å gjette den. Det er hovedgrunnen til at den finnes.

claude mcp add --transport http lovedata https://lovedata.party/mcp

Verktøyene er de samme som endepunktene: søk i fulltekst, slå opp en henvisning som «arbeidsmiljøloven § 15-7», hente en hel paragraf eller et kapittel, se hva som er endret, og få en ferdig sitering i BibTeX eller APA. Et kort sammendrag for maskinlesing ligger på /llms.txt.

Bruker du noe annet enn MCP, er /resolve det viktigste endepunktet. Det tar en henvisning slik den står i en tekst og gir deg ordlyden tilbake, så en modell kan sitere riktig i stedet for å skrive av hukommelsen.

Innhold

• For språkmodeller og agenter
• Kvoter og kø
• Hva som er åpent
• Vilkår
• Autentisering
• Begreper og identifikatorer
• Søkesyntaks
• Endepunkter
• GET /health
• GET /stats
• GET /collections
• GET /facets
• GET /search
• GET /documents
• GET /resolve
• GET /documents/{type}/{id}
• GET /documents/{type}/{id}/text
• GET /documents/{type}/{id}/{paragraf}
• GET /documents/{type}/{id}/chapter/{kapittel}
• GET /documents/{type}/{id}/citation
• POST /citation
• POST /import
• GET /import/check
• GET /changes
• GET /changes/log
• GET /opendata
• GET /opendata/check
• POST /opendata/sync
• POST /mcp
• Objekttyper
• Feil

Kvoter og kø

Kapasiteten er en egenskap ved serveren, ikke ved den enkelte klienten. Derfor deler all trafikk uten token på det samme budsjettet: 360 poeng i minuttet til sammen, for alle som spør akkurat da.

360 poeng er altså rundt 60 søk i minuttet, delt på alle. Er budsjettet brukt opp, blir ikke forespørselen din avvist. Den venter i kø i opptil tolv sekunder, og slipper så til. Det er meningen, og en agent bør vente den ut i stedet for å prøve på nytt med en gang. Blir køen lengre enn det, kommer 429 med Retry-After.

I tillegg har hver enkelt klient et tak på 1800 poeng i timen, slik at én alene ikke kan stå i kø hele døgnet og spise fellesbudsjettet.

Med token er det verken kø eller kvote. Tokenet er nettopp det som skiller.

Hvert svar forteller hvordan det gikk:

/health og de statiske filene teller ikke.

Hva som er åpent

Lesing er åpent for alle. Alt som får serveren til å hente noe utenfra, eller som endrer noe, krever token.

Det finnes ingen måte å slette noe gjennom API-et.

Et token får du ved å spørre den som driver tjenesten. Det deles ut for hånd.

Vilkår

Bruker du tjenesten, gjelder vilkårene. Kort sagt: dette er et uoffisielt oppslagsverktøy og ikke en rettskilde, det gis ingen garantier, og bygger du en KI oppå det har du to plikter. Du skal si fra til dine egne brukere at innholdet er uoffisielt og at lovdata.no gjelder ved tvil, og modellen din skal sitere ordlyden den faktisk hentet med doc_id og paragraf i stedet for å dikte opp lovtekst når et oppslag feiler.

Autentisering

Kjører du din egen instans og setter LOVEDATA_REQUIRE_TOKEN=1, krever alle endepunkter unntatt /health og / et gyldig token:

curl -s -H "Authorization: Bearer $LOVEDATA_TOKEN" "https://lovedata.party/search?q=erstatning"

Token kan også sendes som X-API-Key. Feil eller manglende token gir 401. Tokenene ligger i en fil, én per linje med navn og eventuelt eget budsjett, og leses på nytt når filen endrer seg. Se LOVEDATA_TOKENS_FILE.

Begreper og identifikatorer

En dokument-ID har formen {type}/{dato}-{nummer}, for eksempel lov/2005-06-17-62 eller forskrift/2017-06-20-854. Dette er Lovdatas egen RefID, og den brukes overalt i API-et. Datokoden LOV-2005-06-17-62 godtas av /resolve.

En paragrafnøkkel skrives som §15-7. Endepunktene godtar også 15-7 uten paragraftegn, som er lettere å bruke i URL-er.

Norsk Lovtidend inneholder teksten slik den ble kunngjort, og finnes ved siden av den ajourførte versjonen. Disse dokumentene har derfor egne ID-er på formen lovtidend/forskrift-2026-05-08-891.

Feltet origin sier hvor et dokument kommer fra: corpus er filene i repoet, opendata er hentet fra Lovdatas åpne datasett, og url er importert fra en enkeltadresse.

Feltet in_force er true når date_in_force er passert. Vedtatte lover som ennå ikke er satt i kraft ligger også i basen, og de er markert med false.

Søkesyntaks

q tolkes som et websøk mot en norsk ordstammeindeks. Søk på «oppsigelse» treffer derfor også «oppsigelsen» og «oppsigelser».

Endepunkter

GET /health

Sjekker at API-et og databasen svarer. Krever aldri token.

{ "status": "ok", "service": "lovedata ♥", "version": "1.0.0" }

Svarer 503 hvis databasen ikke er tilgjengelig.

GET /stats

Størrelsen på indeksen og tidspunktet for siste indeksering.

{
  "documents": 5870,
  "provisions": 96946,
  "last_indexed": "2026-09-13T18:28:01.557348Z",
  "by_collection": [{ "collection": "SF", "doc_type": "forskrift", "n": 3417 }]
}

GET /collections

Kildene som finnes lokalt, i den rekkefølgen de vises på forsiden.

{
  "collections": [
    {
      "collection": "NL",
      "doc_types": ["lov"],
      "label": "Lover",
      "description": "Norges lover, ajourført med endringer",
      "documents": 759,
      "first_date": "1687-04-15",
      "last_date": "2026-06-23"
    }
  ]
}

GET /facets

Verdiene en registerliste kan filtreres på, med antall dokumenter bak hver.

Svaret har ministries, years og legal_areas, hver med value og n.

GET /search

Fulltekstsøk på bestemmelsesnivå. Hvert treff er én paragraf, med et utdrag der treffordene er markert med « ».

curl -s --get --data-urlencode "q=personvernombud" --data-urlencode "limit=2" \
  https://lovedata.party/search

{
  "query": "personvernombud",
  "total": 19,
  "limit": 2,
  "offset": 0,
  "hits": [
    {
      "doc_id": "lov/2018-06-15-38",
      "doc_type": "lov",
      "title": "Lov om behandling av personopplysninger (personopplysningsloven)",
      "short_title": "Personopplysningsloven",
      "collection": "NL",
      "legacy_id": "LOV-2018-06-15-38",
      "origin": "corpus",
      "in_force": true,
      "para_key": "§18",
      "para_label": "§ 18",
      "chapter": "Kapittel 5. Personvernombud",
      "heading": "Personvernombudets taushetsplikt",
      "snippet": "«Personvernombud» plikter å hindre at andre får adgang …",
      "body_length": 929,
      "rank": 0.6875,
      "url": "https://lovdata.no/dokument/NL/lov/2018-06-15-38/§18"
    }
  ]
}

total er antall bestemmelser som matcher, ikke antall returnerte. Treffene er sortert på relevans. Hele ordlyden hentes med /documents/{type}/{id}/{paragraf}.

GET /documents

Finn dokumenter på tittel, korttittel eller forkortelse. Søket tåler skrivefeil, så «arbeidsmiljølova» finner arbeidsmiljøloven.

Uten q er dette registerlisten for en hel kilde, slik nettsidene bruker den:

curl -s "https://lovedata.party/documents?collection=NL&sort=title&limit=40"
curl -s --get --data-urlencode "q=sjøloven" https://lovedata.party/documents

Svaret er { "total": …, "limit": …, "offset": …, "documents": [ … ] } der hvert element er et dokumentobjekt.

GET /resolve

Slår opp en henvisning slik den skrives i juridisk tekst og returnerer selve bestemmelsen. Dette er det mest presise endepunktet når du allerede vet hvilken paragraf du er ute etter.

Formene som forstås:

curl -s --get --data-urlencode "ref=sjøloven § 103" https://lovedata.party/resolve

{
  "reference": "sjøloven § 103",
  "resolved": true,
  "document": { "doc_id": "lov/1994-06-24-39", "…": "…" },
  "provision": {
    "seq": 75,
    "para_key": "§103",
    "para_label": "§ 103",
    "chapter": "Kapittel 5. Partrederi",
    "heading": "Bestyrende reder",
    "body": "I ethvert partrederi skal det være en bestyrende reder. …",
    "amendments": "Endret ved lover …",
    "doc_id": "lov/1994-06-24-39",
    "url": "https://lovdata.no/dokument/NL/lov/1994-06-24-39/§103"
  }
}

resolved er false når navnet ikke ble gjenkjent, eller når dokumentet ble funnet men paragrafen ikke finnes. I det siste tilfellet er document satt og note forklarer hva som manglet.

Når flere dokumenter har samme navn, for eksempel gammel og ny forvaltningslov, velges den som er i kraft. De øvrige følger med i alternatives, og note sier hvilket dokument som ble valgt:

{
  "note": "Flere dokumenter heter det samme. Valgte lov/1967-02-10; se alternatives for de øvrige.",
  "alternatives": [
    {
      "doc_id": "lov/2025-06-20-81",
      "title": "Lov om saksbehandlingen i offentlig forvaltning (forvaltningsloven)",
      "date_in_force": null,
      "in_force": false
    }
  ]
}

GET /documents/{type}/{id}

Metadata og innholdsfortegnelse for ett dokument. type er lov eller forskrift, og id er resten av dokument-ID-en.

curl -s https://lovedata.party/documents/lov/2005-06-17-62

Svaret er et dokumentobjekt utvidet med:

full=true er det nettsidene bruker for å vise en hel lov. Store lover har flere hundre bestemmelser, så svaret blir tilsvarende langt. Trenger du bare én paragraf, hent den direkte.

GET /documents/{type}/{id}/text

Hele dokumentet som ren tekst, med tittel og datokode øverst. Praktisk for grep, diffing og videre tekstbehandling.

curl -s https://lovedata.party/documents/lov/1987-06-12-48/text | head -20

GET /documents/{type}/{id}/{paragraf}

Ordlyden i én paragraf. Paragrafen kan skrives som 15-7, §15-7 eller prosentkodet %C2%A715-7.

curl -s https://lovedata.party/documents/lov/2005-06-17-62/15-7

{
  "document": { "doc_id": "lov/2005-06-17-62", "…": "…" },
  "provision": {
    "seq": 145,
    "para_key": "§15-7",
    "para_label": "§ 15-7",
    "chapter": "Kapittel 15. Opphør av arbeidsforhold",
    "heading": "Vern mot usaklig oppsigelse",
    "body": "(1) Arbeidstaker kan ikke sies opp uten at det er saklig begrunnet …",
    "amendments": "Endret ved lover …",
    "doc_id": "lov/2005-06-17-62",
    "url": "https://lovdata.no/dokument/NL/lov/2005-06-17-62/§15-7"
  }
}

Dokumenter uten paragrafinndeling, som mange delegeringsvedtak, har hele teksten i én bestemmelse med para_key lik null og anker dokument.

GET /documents/{type}/{id}/chapter/{kapittel}

Alle paragrafene i ett kapittel. kapittel kan være nummeret eller en del av kapitteltittelen, og sammenligningen er ufølsom for store og små bokstaver.

curl -s "https://lovedata.party/documents/lov/2005-06-17-62/chapter/14"

{
  "document": { "doc_id": "lov/2005-06-17-62", "…": "…" },
  "chapter": "Kapittel 14. Ansettelse mv.",
  "provisions": [{ "para_label": "§ 14-1", "heading": "Informasjon om ledige stillinger i virksomheten", "…": "…" }]
}

GET /documents/{type}/{id}/citation

Siteringen av dokumentet, som BibTeX-post og ferdige henvisninger. Formen følger oppsettet i thmmsn/latex, der rettskilder føres som @misc med datokoden i number og Lovdata som institution, og paragrafen oppgis i selve henvisningen.

curl -s --get --data-urlencode "para=§ 15-7" \
  "https://lovedata.party/documents/lov/2005-06-17-62/citation"

{
  "key": "arbeidsmiljoloven2005",
  "bibtex": "@misc{arbeidsmiljoloven2005,\n  author       = \"{Arbeidsmiljøloven}\", …",
  "parencite": "\\parencite[§ 15-7]{arbeidsmiljoloven2005}",
  "textcite": "\\textcite[§ 15-7]{arbeidsmiljoloven2005}",
  "plain": "(Arbeidsmiljøloven, 2005, § 15-7)",
  "apa": "Arbeidsmiljøloven. (2005). Lov om arbeidsmiljø … (LOV-2005-06-17-62). Lovdata. https://…"
}

Lover og forskrifter føres under korttittelen, mens en avgjørelse føres under sin egen ident med stikkordene som tittel, slik norsk APA-praksis gjør det:

@misc{tosl2026117452,
  author       = "{TOSL-2026-117452}",
  title        = "{Strafferett. Kroppskrenkelse. Tilståelsesdom. Straffeloven § 271}",
  year         = 2026,
  number       = "TOSL-2026-117452",
  url          = "https://lovdata.no/dokument/TRSTR/avgjorelse/tosl-2026-117452",
  institution  = "Lovdata",
  note         = "Oslo tingrett · Dom. Hentet fra Lovdata",
}

Referanselisten skal vise leseren hvor kilden finnes offisielt, så url og source_url peker på Lovdata. Det er det eneste stedet i tjenesten som gjør det, og det gjelder bare siteringer.

POST /citation

Som GET /documents/{type}/{id}/citation, men tar imot ordlyden du siterer i kroppen, slik at lange utdrag slipper å gå gjennom URL-en.

curl -s -X POST https://lovedata.party/citation -H 'content-type: application/json' \
  -d '{"doc_id":"lov/2005-06-17-62","para":"§ 15-7","quote":"Arbeidstaker kan ikke sies opp …"}' \
  | jq -r .textcquote

Er quote satt, følger sitatformene med i svaret: textcquote og blockcquote fra csquotes, quote_plain med anførselstegn, og quote_full med adressen under. block sier om utdraget er langt nok til å settes som eget avsnitt.

POST /import

Krever token. Henter ett dokument fra en adresse på lovdata.no, leser ut metadata, kategoriserer innholdet og legger det i basen. Etterpå er dokumentet søkbart sammen med resten.

curl -s -X POST https://lovedata.party/import -H 'content-type: application/json' \
  -d '{"url":"https://lovdata.no/dokument/TRSTR/avgjorelse/tosl-2026-117452"}'

{
  "imported": true,
  "doc_id": "avgjorelse/tosl-2026-117452",
  "doc_type": "avgjorelse",
  "collection": "TRSTR",
  "title": "TOSL-2026-117452",
  "instance": "Oslo tingrett – Dom",
  "categories": ["Strafferett", "Tingretten", "Dom"],
  "keywords": "Strafferett. Kroppskrenkelse. Tilståelsesdom. Straffeloven § 271.",
  "summary": "En mann ble dømt for kroppskrenkelse …",
  "provisions": 1,
  "url": "/dokument/avgjorelse/tosl-2026-117452"
}

Kategoriene utledes av dokumentet selv. Rettsområdet hentes fra stikkordene, og instans og avgjørelsestype fra instansfeltet, slik at en tingrettsdom havner i sin egen samling.

Importen henter bare den ene siden du oppgir, og følger ingen lenker videre. En adresse som ikke peker på et dokument, eller et dokument som krever innlogging, gir 400 med en forklaring.

GET /import/check

Ser om en adresse alt finnes i basen, uten å hente noe fra lovdata.no.

curl -s --get --data-urlencode "url=https://lovdata.no/dokument/NL/lov/2005-06-17-62" \
  https://lovedata.party/import/check | jq '{known, doc_id, origin_text}'

Svarer known: false med den utledede doc_id-en hvis dokumentet ikke finnes, og ellers hva basen har: tittel, hvor det kom fra og når det ble hentet.

GET /changes

Lover og forskrifter der en endring har trådt i kraft i perioden. Dette er den juridiske endringen, altså hva som gjelder nå og ikke gjaldt før. Grunnlaget er feltene Lovdata selv fører om siste endring, så dette virker uten at du har synkronisert noe.

curl -s "https://lovedata.party/changes?since=2026-07-01&type=lov&limit=10"

Hvert dokument har feltet changed_on med datoen endringen trådte i kraft, og last_changed_by med vedtaket som endret det.

GET /changes/log

Hva som ble nytt, endret eller fjernet i den lokale basen sist innhold ble hentet inn. Dette er den tekniske forskjellen mellom to synkroniseringer, og bygger på et fingeravtrykk av hvert dokument.

{
  "total": 3,
  "entries": [
    {
      "detected_at": "2026-09-13T21:50:38Z",
      "doc_id": "forskrift/2026-09-11-1772",
      "change": "ny",
      "source": "gjeldende-sentrale-forskrifter.tar.bz2",
      "title": "Delegering av Kongens myndighet …",
      "last_changed_by": null,
      "url": "/dokument/forskrift/2026-09-11-1772"
    }
  ],
  "sources": [{ "source": "gjeldende-lover.tar.bz2", "last_run": "…", "n": 759 }]
}

Første synkronisering av et datasett fører opp alt som endret, fordi det ikke finnes noe fingeravtrykk å sammenligne med ennå. Fra og med andre gang er tallene reelle.

GET /opendata

Datasettene Lovdata publiserer som åpne data under NLOD 2.0, og når de sist ble hentet inn lokalt.

{
  "datasets": [
    {
      "filename": "gjeldende-lover.tar.bz2",
      "description": "Gjeldende lover, ajourført med endringer",
      "size_bytes": 5811395,
      "last_modified": "2026-09-10T01:31:00Z",
      "synced_at": null,
      "documents": null
    }
  ]
}

Svarer 502 hvis api.lovdata.no ikke er tilgjengelig.

GET /opendata/check

Spør Lovdata om det finnes nyere utgaver enn det som ligger lokalt, uten å laste ned noe.

{
  "checked_at": "2026-09-13T21:48:02Z",
  "updates_available": 1,
  "datasets": [
    {
      "dataset": "gjeldende-lover.tar.bz2",
      "last_modified": "2026-09-10T01:31:00Z",
      "synced_at": "2026-09-13T21:50:48Z",
      "documents": 759,
      "never_synced": false,
      "update_available": false
    }
  ]
}

POST /opendata/sync

Krever token.

Laster ned ett datasett, pakker det ut og indekserer dokumentene. Kallet svarer først når indekseringen er ferdig, og store datasett tar flere minutter.

curl -s -X POST https://lovedata.party/opendata/sync -H 'content-type: application/json' \
  -d '{"dataset":"lovtidend-avd1-2026.tar.bz2"}'

{
  "dataset": "lovtidend-avd1-2026.tar.bz2",
  "documents": 988,
  "provisions": 3292,
  "seconds": 4.3,
  "new": 0,
  "changed": 0,
  "removed": 0
}

Tallene for new, changed og removed gjelder denne kjøringen, og er det samme som legges i endringsloggen.

Dokumenter fra et datasett erstattes i sin helhet ved neste synkronisering. Importerte enkeltdokumenter røres ikke.

POST /mcp

MCP over streamable HTTP, slik at Claude Code og andre MCP-klienter kan bruke de samme oppslagene som verktøy. Meldingene er JSON-RPC 2.0.

claude mcp add --transport http lovedata https://lovedata.party/mcp

Metodene som støttes er initialize, tools/list, tools/call og ping. Notifikasjoner besvares med 202 og tom kropp. Direkte kall ser slik ut:

curl -s -X POST https://lovedata.party/mcp -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
       "params":{"name":"resolve_reference","arguments":{"reference":"aml § 15-7"}}}'

Resultatet er JSON-teksten fra det tilsvarende REST-endepunktet, pakket i result.content[0].text. Oppslag som ikke finnes gir isError: true med en forklaring på norsk, ikke en JSON-RPC-feil.

Objekttyper

Dokument

Bestemmelse

Feil

Feil følger FastAPIs standardform, {"detail": "…"}.

Et oppslag som ikke finner noe er ikke en feil i /search og /resolve. De svarer 200 med tom treffliste eller resolved: false.

Nettsidene

Tjenesten serverer også en søkeflate på samme port. Disse adressene gir HTML:

Dokumentsiden har et eget søkefelt som leter inne i det åpne dokumentet. Det bruker samme ordstammesøk som resten av tjenesten, markerer forekomstene i teksten, merker treffene i innholdsfortegnelsen, og lar deg hoppe mellom dem eller skjule alt annet. Høyreklikk i en bestemmelse gir et ferdig sitat med referanse, i LaTeX og i ren tekst.

Merk

Dette er et lokalt oppslagsverktøy, ikke en rettskilde. Ved tvil gjelder den offisielle teksten Lovdata publiserer. Innholdet er hentet fra Lovdatas åpne datasett under NLOD 2.0, og fra enkeltdokumenter du selv importerer.