Fortnox API, från någon som byggt mot det sedan 2014

Jag byggde min första koppling mot Fortnox 2014, åt en webbshop som fortfarande skickar sina order dit varje dag. Sen dess har API:et bytt inloggningsmodell, fått tjänstekonton och ändrat en del på vägen. Det här är genomgången jag själv hade velat ha från början. Den är skriven för utvecklare, men går att följa även om du mest vill förstå vad du beställer.

Vad Fortnox API täcker

Fortnox API är ett REST-API som pratar JSON, med adressen https://api.fortnox.se/3/. Det täcker det mesta som går att göra i Fortnox:

• Order, offerter och fakturor, inklusive betalningar
• Kunder, leverantörer och leverantörsfakturor
• Artiklar, priser och lager
• Projekt, avtal och återkommande fakturering
• Verifikationer, konton och räkenskapsår
• Tidrapportering, anställda och lönetransaktioner
• Filer och bilagor

Allt finns beskrivet i Fortnox API-dokumentation. Dokumentationen är bra, men den säger inte så mycket om vad som händer när saker går fel. Det är resten av den här sidan till för.

Så fungerar inloggningen

Fortnox använder OAuth 2 med så kallad authorization code flow. Gången ser ut så här:

1. Du skapar din integration i Fortnox utvecklarportal och får ett klient-id och en klienthemlighet.
2. Kunden skickas till https://apps.fortnox.se/oauth-v1/auth med ditt klient-id, en redirect-adress och de scopes du vill ha.
3. Kunden loggar in i Fortnox och godkänner att din integration får åtkomst.
4. Fortnox skickar tillbaka kunden till din redirect-adress med en kod.
5. Du byter koden mot en access token och en refresh token.

Själva bytet är ett vanligt POST-anrop, där klient-id och klienthemlighet skickas som Basic-autentisering:

curl -X POST https://apps.fortnox.se/oauth-v1/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&code=$CODE&redirect_uri=$REDIRECT_URI"

Sen använder du access token i varje anrop:

curl https://api.fortnox.se/3/customers \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Accept: application/json"

Tjänstekonton

Godkänner en vanlig användare kopplingen hänger den ihop med just den personen. Slutar personen, eller tas hens behörighet bort, slutar kopplingen fungera. För integrationer mellan system är det sällan vad du vill.

Lösningen är ett tjänstekonto. Du lägger till parametern account_type=service i inloggningen, och då kopplas åtkomsten till en särskild användare i stället för en person. Det kan bara finnas ett tjänstekonto per klient-id och kund, och bara en systemadministratör hos kunden kan godkänna det. Bygger du något nytt i dag är det här nästan alltid rätt val. Webbshopen jag nämnde flyttades över till tjänstekonto 2026.

Scopes

Scopes styr vad integrationen får komma åt, till exempel customer, order och article. De skickas med i inloggningen, separerade med mellanslag. Be bara om det du behöver. Räkna också med att kunden får godkänna kopplingen på nytt om du lägger till fler scopes senare, så det lönar sig att tänka igenom listan från början.

Tokens, och varför de ställer till det

En access token gäller i en timme. En refresh token gäller i 45 dagar, och varje gång du använder den för att hämta en ny access token får du också en ny refresh token. Den gamla slutar fungera direkt. Förnyelsen är ett anrop till samma adress som bytet ovan, med grant_type=refresh_token och din senaste refresh token.

Det låter enkelt, men det är här de flesta kopplingar går sönder:

• Två processer förnyar samtidigt. Den ena får en ny refresh token och den andra sitter kvar med en som inte längre gäller. Nästa gång står kopplingen still. Låt bara ett ställe i koden förnya, och spara den nya token innan du gör något annat.
• Kopplingen står oanvänd för länge. Går det mer än 45 dagar utan en förnyelse är refresh token ogiltig, och kunden får godkänna kopplingen igen. Säsongsflöden är lömska här.
• Felet syns inte. En koppling som tappar sin token slutar tyst att skicka data. Logga varje misslyckad förnyelse och se till att någon får veta det.

Jag har själv suttit och felsökt precis den här sortens token-problem, så ta det på allvar från början.

Anropsgränser

Enligt Fortnox beskrivning av anropsgränserna får du göra 300 anrop per minut per klient och kund. Gränsen räknas i ett glidande fönster på fem sekunder, så i praktiken är det 25 anrop per fem sekunder som gäller.

Vid vanlig drift märks det sällan. Det märks när du ska läsa in eller uppdatera stora mängder på en gång, som hela artikelregistret första gången. Bygg in en paus mellan anropen och hantera felsvaren när du slår i taket, så att importen fortsätter i stället för att tappa poster.

Integrationslicensen

För att din integration ska få prata med kundens Fortnox behöver kunden en integrationslicens. Den beställs i Fortnox och kostar enligt Fortnox prislista 189 kronor i månaden. Licensen gäller för alla integrationer kunden har, så har kunden redan en app kopplad behövs ingen ny. Nämn den för kunden innan bygget sätter igång, för det är den första frågan som kommer när något inte fungerar.

Vill du hellre att någon annan bygger?

Allt det här går att bygga själv, och har du en utvecklare i huset kan det vara rätt väg. Vill du hellre slippa hålla koll på tokens och anropsgränser bygger jag kopplingen åt dig, till fast pris. Mer om det, och om vad det kostar, på sidan om Fortnox-integration.

Uppdaterad 28 september 2026