Varje rad bär ett eget fält för Brytande eller Bakåtkompatibel. Du ska kunna svara på frågan "behöver jag göra något?" utan att läsa texten.
Ändringar totalt
5
Varav brytande
0
Bakåtkompatibel
Idempotensen håller nu även för samtidiga omförsök
Idempotency-Key skyddade hittills en omsändning som gjordes EFTER att det första anropet svarat. Men det fel huvudet finns för är att nätverket tappar svaret medan anropet fortfarande pågår: din klient ser en timeout efter några sekunder och skickar om, och båda anropen var då igång samtidigt. Fem samtidiga anrop med samma nyckel gav fem verifikat. NYCKELN TAS NU I ANSPRÅK INNAN ARBETET BÖRJAR, och kapplöpningen avgörs i databasen: exakt ett anrop får skriva. NY FELKOD: 409 `idempotency_in_progress` betyder att ett anrop med samma nyckel behandlas just nu. Skicka om exakt samma anrop om några sekunder så får du det första svaret. BYT INTE NYCKEL och skapa inte ett nytt anrop — det första kan mycket väl ha bokfört. Koden är ny och tillkommer vid sidan av `idempotency_conflict`, som fortsatt betyder samma nyckel med en ANNAN kropp. ETT NEKAT ANROP SLÄPPER NYCKELN, precis som förut: får du 400 eller 422 kan du rätta kroppen och skicka om med samma referens. Inga fält, statuskoder eller befintliga felkoder ändrar betydelse.
/api/v1/verifikat/api/v1/kundfakturor
Bakåtkompatibel
Belopp och texter i ett verifikat har uttalade gränser
Ett enskilt belopp och verifikatets summa måste rymmas i 9 999 999 999,99 kronor — kolumnernas verkliga gräns, som tidigare gav ett svårläst databasfel i stället för ett besked. Beskrivningen får vara högst 500 tecken, motparten 200 och radens anteckning 500. Gränserna avvisas med 400 och en mening som säger vilket fält som är för stort. Ett anrop som höll sig inom det rimliga påverkas inte.
/api/v1/verifikat
Bakåtkompatibel
POST /api/v1/verifikat — bokför en affärshändelse från ditt eget system
Adressen som hittills bara gick att läsa tar nu emot skrivningar. En nyckel med behörigheterna Bokföra och Läsa kan skriva ett verifikat direkt i huvudboken — serie, datum, beskrivning, motpart och minst två rader med konto, debet och kredit. Kostnadsställe och projekt går att sätta per rad. VERIFIKATET SKRIVS GENOM MOTORNS EGEN FUNKTION, alltså samma väg som bokföringsformuläret i programmet: balanskravet, kravet på ett belopp skilt från noll, minst två rader, att kontot finns och är aktivt, periodlåset, momslåset och avslutade räkenskapsår gäller identiskt. Ett anrop som stoppas av ett lås får 422 med skälet utskrivet; en kropp som inte går att läsa får 400. IDEMPOTENCY-KEY ÄR OBLIGATORISKT, därför att ett verifikat inte går att ta bort — en dubbelpost rättas med ett ändringsverifikat och syns för alltid. Skicka din egen externa referens som nyckel: samma referens igen ger samma verifikat tillbaka, med svarshuvudet Idempotent-Replay. SVARET BÄR VÄGEN TILLBAKA: verifikatets id, serie, nummer, etiketten som står i huvudboken (A12) och en länk till posten i din egen installation. RUTTEN SKAPAR ALDRIG KONTON och låter dig aldrig välja källa — ett konto som saknas ger 422 med numret utskrivet, och systemkällorna är förbehållna programmets egna bokningar. GET på samma adress är oförändrad, ned till fältnamnen.
/api/v1/verifikat
Bakåtkompatibel
API v1: egna nycklar, tre nya endpoints och ett enhetligt felformat
Installationen har nu ett eget API med nycklar du skapar själv under Inställningar → API-nycklar. Nyckeln bär identitet, behörighet och en kvot, syns i en lista med när och varifrån den senast användes, och återkallas med ett klick — återkallelsen biter i samma sekund, även mitt i ett pågående anrop. TRE NYA ENDPOINTS: /api/v1/meta säger vilken version installationen kör och vad din nyckel får göra, /api/v1/verifikat lämnar ut affärshändelser med sina rader och markörsidindelning, och /api/v1/kundfakturor skapar ett fakturautkast som kan bokföras direkt. INGENTING GAMMALT SLUTAR FUNGERA. STATS_API_KEY, ORDER_INBOUND_SECRET och PEPPOL_INBOUND_SECRET fortsätter fungera oförändrat, ned till felkropparna, och kan användas parallellt med de nya nycklarna. De befintliga rutterna svarar likadant som förut; det som tillkommit är en andra väg in. FELFORMATET är nu detsamma på hela ytan: en stabil maskinkod i error, en förklaring på svenska i message, strukturerad detail och ett request_id i både kropp och X-Request-Id. Befintliga felkoder behåller sin betydelse ordagrant — enhetligheten kom genom att message lades till där den saknades, aldrig genom att error ändrades.
De två byrårutterna är orörda: samma form, samma felkoder, samma schema_version. De använder ett eget nyckelformat (dkb_) i en egen tabell och berörs inte av de nya API-nycklarna. Kontraktet är fryst och får bara utökas bakåtkompatibelt — den här loggen kommer aldrig att visa en brytande rad för de två adresserna.
/api/byra/token/api/stats/byra
Vad som räknas som brytande
Ett borttaget eller omdöpt fält, en ändrad betydelse eller enhet, en felkod som byter innebörd, en parameter som blir obligatorisk, eller en statuskod som byter mening. Nya endpoints, nya valfria parametrar och nya fält i ett svar är det inte — en integration som ignorerar fält den inte känner igen påverkas aldrig av dem.
Byråkontraktet får aldrig en brytande rad./api/byra/token och /api/stats/byra läses av byråportalen, som är en separat produkt. De får utökas bakåtkompatibelt och ingenting annat. Läs kontraktet.