Recept

Byråportalens kontrakt

Ett eget spår med ett eget nyckelformat. Byrån växlar sin nyckel mot en kortlivad token och läser ett aggregat — en rad, inga affärshändelser.

Det här kontraktet är fryst

De två adresserna läses av byråportalen, som är en separat produkt. De får utökas bakåtkompatibelt — nya fält en gammal läsare kan ignorera — och ingenting annat. Inget fält tas bort, inget byter betydelse, schema_version sänks aldrig, och ändringsloggen kommer aldrig att visa en brytande rad för dem.

Debet & Kredit kör på din egen server, så bas-URL:en är din — inte vår. Skriv in den här, så byts den ut i varje kodexempel i dokumentationen.

Klienten utfärdar nyckeln, inte byrån

Nyckeln är en rad i klientens egen databas, skapad av klientens egen administratör under Inställningar → Byråns åtkomst. Byrån kan inte ge sig själv åtkomst, och den som kan ge kan också ta tillbaka. En nyckel som bara byrån råder över är inlåsning med extra steg.

Klienten ser i sitt eget gränssnitt vilka byråer som har åtkomst och när nyckeln senast användes, och återkallar med ett klick. Återkallelsen biter i samma sekund — även för en byrå som redan är inloggad och har en token som ännu inte gått ut.

Nyckeln räcker för att LÄSA. Den räcker inte för att bokföra: till det behöver handläggaren ett eget konto i klientens installation, med rollen Medarbetare, som klienten lägger upp under Inställningar → Användare. Två saker, båda utfärdade av klienten, och ingen av dem ersätter den andra — Ge din redovisningsbyrå åtkomst är stegen ur klientens perspektiv.

Steg 1: växla nyckeln mot en token

Byrånyckeln har prefixet dkb_ och är ett annat format än installationens egna API-nycklar. Den skickas bara hit, aldrig till någon annan adress.

curl -X POST https://din-installation.se/api/byra/token \
  -H "Authorization: Bearer dkb_DIN_BYRANYCKEL"
{
  "access_token": "eyJhbGciOi…",
  "token_type": "Bearer",
  "expires_in": 3600,
  "expires_at": 1789000000,
  "scopes": [
    "stats:read"
  ],
  "agency": "Redovisningsbyrån AB"
}

Steg 2: läs aggregatet

Token lever en timme. Portalen ska växla nyckeln på nytt när den går ut, inte bygga en egen sessionshistorik i klientens databas.

curl https://din-installation.se/api/stats/byra \
  -H "Authorization: Bearer eyJhbGciOi…"
{
  "schema_version": 1,
  "installation_schema_version": 112,
  "period": "202609",
  "unbooked_count": 4,
  "attachments_missing": 3,
  "unmatched_bank": 4,
  "last_verification": "2026-09-01",
  "period_locked_to": "2026-03-31",
  "vat_due_date": "2026-05-12",
  "fiscal_year": {
    "start": "2026-01-01",
    "end": "2026-12-31",
    "status": "open"
  },
  "last_closed_month": "2026-07-01",
  "open_month": "2026-08-01",
  "open_month_status": "in_progress",
  "open_month_failing": [
    "bank",
    "underlag"
  ],
  "months_behind": 2
}

Detta är allt en byrånyckel visar

  • Antal obokförda händelser
  • Antal omatchade banktransaktioner
  • Antal verifikat som saknar underlag
  • Datum för senaste verifikatet
  • Till och med vilket datum bokföringen är låst
  • Nästa momsdeadline
  • Räkenskapsårets start, slut och status
  • Senast avslutade bokföringsmånad
  • Vilken månad som står näst i tur att avslutas, och om den är påbörjad
  • Vilka villkor i månadsavslutet som är röda i den månaden — villkorens namn, inga belopp och inga motparter. Lönen och skattekontot står aldrig där
  • Hur många avslutade månader som ännu inte kvitterats

Inga belopp, inga motparter, inga verifikat. Nyckeln når inte lönespecar, personal, kunder, leverantörer, underlag eller klientens sparade nycklar — och det upprätthålls av databasen, inte av gränssnittet. Klienten kan hämta exakt samma svar med sin egen inloggning och räkna fälten själv.

Två versionstal, två frågor

FältSvarar på
schema_versionKan portalen läsa det här svaret? Bumpas bara vid en ändring som inte är rent additiv.
installation_schema_versionHur gammal är klientens installation? Antalet körda migrationer, som ökar av sig självt vid varje uppgradering. 0 betyder okänt — då ska portalen säga att den inte vet i stället för att gissa.

Skilj återkallelse från haveri

Felkoderna är en del av kontraktet, inte formuleringar. En klient som dragit in nyckeln är ett normalt tillstånd som ska visas som just det — blandas det ihop med ett fel ser en legitim återkallelse ut som ett driftstopp.

  • key_revoked (växlingen) och no_access (läsningen) betyder samma sak för portalen: åtkomsten är indragen.
  • unauthorized betyder att nyckeln eller token är okänd eller felformad.
  • token_unavailable och db_error är de enda som är haverier. Försök igen.

Vidare