En Fortnox-integration ritas ofta som en pil: order, tidrapport eller leverantörsfaktura lämnar ett system och hamnar i Fortnox. När API-anropet får ett lyckat svar ser arbetet färdigt ut. Men ett tekniskt svar säger inte automatiskt att rätt affärshändelse överfördes, att den inte redan fanns eller att bokföringsunderlaget blev korrekt i sitt sammanhang.
Det skapar en dold arbetskö. Någon behöver i efterhand reda ut poster som saknas, blev dubbla, stoppades av ett konto som inte finns eller fick ett okänt resultat när anslutningen bröts. Om integrationen bara lagrar ”grönt” eller ”rött” går det inte att se vad verksamheten faktiskt vet.
Min utgångspunkt är därför: bygg en bokföringsgräns, inte bara ett API-flöde. Gränsen ska skilja mellan att verksamheten har godkänt en händelse, att en överföring har begärts, att Fortnox har bekräftat en resurs och att resultatet har stämts av. Först när de fyra kvittona är begripliga går det att välja mellan Zapier, n8n, egen kod eller en annan integrationslösning.
Det här är ett tekniskt och operativt beslutsramverk. Det är inte redovisnings-, skatte-, juridisk eller säkerhetsrådgivning. Bokföringsregler, kontoplan, moms, verifikationer, behörigheter och ansvar behöver bedömas av rätt personer för den aktuella verksamheten.
Fyra kvitton som inte får blandas ihop
En stabil integration behöver kunna svara på fyra olika frågor. De kan ligga i samma databas eller arbetsyta, men de ska inte reduceras till en enda status.
1. Är affärshändelsen godkänd?
Källsystemet har en stabil identitet för händelsen och de uppgifter som krävs för nästa steg. För en faktura kan det handla om kund, datum, belopp, valuta och rader. För ett bokföringsunderlag kan andra fält och kontroller krävas. ”Godkänd” är verksamhetens beslut enligt en uttrycklig regel, inte att ett automatiseringsverktyg lyckades läsa posten.
Spara minst käll-id, version eller ändringstid, belopp, datum och vilken regel som godkände händelsen. Då går det senare att se vilken avsikt integrationen försökte genomföra.
2. Har överföringen begärts?
Integrationen har skapat en operationsidentitet och skickat eller köat en begäran. Spara tidpunkt, käll-id, operationstyp och en begränsad teknisk referens. Logga inte fler personuppgifter eller hemligheter än felsökningen behöver.
Det här kvittot bevisar bara att integrationen försökte. Ett nätverksanrop kan nå Fortnox även om svaret försvinner på vägen tillbaka. Om samma händelse då skickas igen utan kontroll kan en dubblett uppstå.
3. Har Fortnox bekräftat resursen?
Integrationen behöver tolka det svar och den felinformation som den aktuella Fortnox-operationen faktiskt returnerar. Om svaret innehåller en målreferens bör den sparas tillsammans med käll-id och operations-id. Kontrollera detaljerna mot den aktuella Fortnox-dokumentationen för den resurstyp ni använder.
Ett 2xx-svar är värdefullt bevis för överföringen. Det är däremot inte ett generellt intyg om att hela bokföringen är riktig. Integrationen måste fortfarande veta vilken resurs som skapades, med vilket underlag och hur den ska kontrolleras.
4. Är resultatet avstämt?
En definierad kontroll har jämfört källa och Fortnox. Kontrollen kan exempelvis verifiera att förväntade poster finns exakt en gång, att belopp och datum matchar den godkända händelsen och att inga poster har fastnat i ett mellanläge.
Avstämningen ska ha en ägare och en frekvens. Den kan vara automatisk, manuell eller blandad. Det viktiga är att ”avstämd” betyder en verklig kontroll — inte att senaste körningen var grön.
Förvalidera innan integrationen skriver
Kontrollera förutsättningarna innan en skrivning. Fortnoxs utvecklaravtal kräver att API:t används enligt leverantörens instruktioner och att den integrerade lösningen testas även efter ändringar i API:t (Fortnoxs utvecklaravtal). Det är en bra driftregel även när transporten går genom ett integrationsverktyg.
Ett första valideringslager kan svara på:
- finns de identiteter och obligatoriska fält som nästa operation behöver;
- finns och är de aktuella konton eller andra referenser som flödet använder;
- har samma källhändelse redan fått en målreferens;
- har underlaget ändrats sedan det godkändes;
- är operationen tillåten för just den här typen av post;
- ska avvikelsen stoppas eller skickas till en människa.
Förvalidering ersätter inte redovisningsbedömning. Den gör i stället tekniskt upptäckbara fel begripliga innan integrationen skapar en halvfärdig kedja. Lägg också in ett litet testfall för varje regel och upprepa testen när leverantörens tekniska villkor ändras.
Ett lyckat API-anrop är ett överföringsbevis
Ett lyckat svar visar att målplattformen behandlade den aktuella begäran enligt det tekniska kontraktet. Det är ett viktigt kvitto, men inte ett generellt intyg om att hela bokföringen är riktig. Integrationen måste fortfarande veta vilken resurs som skapades, med vilket underlag och hur resultatet ska kontrolleras.
Säg därför inte bara ”synkad”. Använd mer precisa tillstånd:
- validerad: källhändelsen får gå vidare;
- begärd: operationen har skickats eller köats;
- bekräftad: målplattformen har svarat och resursreferensen är sparad;
- avstämd: den definierade kontrollen har passerat;
- undantag: en människa eller särskild regel måste avgöra nästa steg.
Skillnaden gör supporten enklare. Om en post är ”begärd” men inte ”bekräftad” ska teamet kontrollera målstatus före ett nytt försök. Om den är ”bekräftad” men inte ”avstämd” behövs en kontroll, inte nödvändigtvis en ny skrivning.
Behandla autentisering och behörighet som driftansvar
Välj autentiseringsmetod och åtkomst utifrån det aktuella Fortnox-upplägget och den tekniska dokumentation som gäller när lösningen byggs. Utvecklaravtalet kan ändras, och det beskriver också att användningen sker på eget ansvar utan en generell garanti för API:ts kvalitet, säkerhet, tillgänglighet eller prestanda (Fortnoxs utvecklaravtal). Det är ett skäl att planera för förändring och kontroll, inte ett skäl att avstå från tydlig drift.
Tokens och andra hemligheter ska lagras säkert på serversidan. De hör inte hemma i ett kalkylblad, ett synligt webhook-fält eller klientkod. Begär bara den åtkomst lösningen behöver, håll test och produktion åtskilda och bestäm vem som får ansluta eller återansluta ett företag.
Integrationen behöver dessutom kunna upptäcka att en credential inte längre fungerar och skapa en begriplig uppgift för rätt ägare. Ett autentiseringsfel ska inte bli hundratals identiska återförsök eller en tyst kö som växer.
Belastningsgränser kräver kö, inte panik
Kontrollera alltid aktuella belastningsgränser för det Fortnox-upplägg som ska användas. Leverantörsvillkor och tekniska gränser kan ändras, så bygg inte en batch utifrån ett gammalt tal i en artikel eller ett test.
Praktiskt innebär det att ett större importjobb behöver kontrollerad takt, kö och återförsök. Men alla fel ska inte försöka igen:
- tillfällig begränsning kan vänta och försöka igen med begränsad frekvens;
- valideringsfel ska rättas, inte bombarderas;
- autentiseringsfel ska stoppa den berörda anslutningen;
- okänt utfall ska kontrolleras mot målplattformen innan samma avsikt skickas igen;
- permanent avvisning ska få en ägare och en begriplig orsak.
Sätt ett tak för antal försök och flytta sedan posten till undantagsarbetsytan. Annars kan ett automatiskt återförsök bli en kostsam och svårtolkad bakgrundsprocess.
Händelser kan starta flödet — avstämning avslutar det
Om det valda Fortnox-upplägget erbjuder händelser kan de starta ett kontrollflöde, men en händelse bör inte behandlas som hela sanningen. Hämta eller kontrollera den aktuella resursen innan du fattar beslut, gör hanteringen dubblettsäker och komplettera med periodisk avstämning.
Om polling används behövs pagination, en sparad kontrollpunkt och en plan för överlapp så att en post inte tappas vid gränsen mellan två körningar. Samma princip gäller oavsett om flödet startar med en händelse, en schemalagd körning eller ett manuellt beslut: avstämningen avslutar inte förrän den jämför källa och mål.
Bygg undantagsarbetsytan för beslut
Ett felloggfönster är inte en arbetsyta. Den person som tar hand om ett undantag behöver se:
- käll-id och eventuell Fortnox-referens;
- senast bekräftade steg;
- operationen som försöktes;
- begriplig orsak och teknisk referens;
- vad som redan kan ha hänt;
- rekommenderade säkra utgångar;
- ansvarig roll och tidpunkt för uppföljning;
- historik över tidigare beslut och försök.
Utgångarna kan vara ”rätta data och fortsätt”, ”kontrollera målpost”, ”markera som redan utförd”, ”avbryt med orsak” eller ”eskalera till system- eller redovisningsansvarig”. Varje beslut ska skriva ett nytt kvitto. Det räcker inte att ta bort den röda raden.
Den här delen avgör ofta om integrationen minskar administrativt arbete eller bara flyttar det till en osynlig kö.
Zapier, n8n eller egen kod?
Fortnox-gränsen bör vara densamma oavsett transportverktyg. Verktyget ska kunna bära identitet, bevis, begränsade återförsök och tydliga undantag.
Zapier dokumenterar flera sätt att göra API-anrop, där bland annat Webhooks by Zapier och API Request actions har olika egenskaper för autentisering och konfiguration. Ett webhook-steg kan vara snabbt att prova, men hemligheter i ett konfigurationsfält behöver hanteras medvetet. Kontrollera alltid aktuell funktionalitet, plan, historik och säkerhetsmodell i det konto ni faktiskt använder. Den här artikeln påstår inte att det finns en viss inbyggd Fortnox-connector.
n8n har en generell HTTP Request-node som kan anropa REST-API:er. Det kan ge mer explicit kontroll över flöde och felhantering, men någon måste fortfarande äga credentials, workflow-versioner, körningshistorik, uppgraderingar och drift för den valda installationen. Self-hosting gör inte integrationen korrekt av sig själv.
Egen kod kan passa när dubblettskydd, ordningskrav, datamodell eller granskningsspår inte kan uttryckas säkert i verktyget. Det innebär samtidigt mer ansvar för test, övervakning och förvaltning.
Välj alltså efter felmodellen: hur upptäcks ett okänt resultat, vem äger undantaget och hur bevisas avstämningen? Antalet appar i en katalog är sekundärt.
Ett säkert första test
Börja med en avgränsad resurstyp och ofarlig testdata. Dokumentera vilken Fortnox-miljö, vilken åtkomst och vilken kontoplan eller referensdata testet använder. Kör sedan scenarier som visar mer än happy path:
- samma källhändelse kommer två gånger;
- Fortnox tar emot begäran men svaret når inte integrationen;
- ett konto eller obligatoriskt fält saknas;
- anslutningen har gått ut eller återkallats;
- en tillfällig belastningsgräns uppstår mitt i en batch;
- källposten ändras efter godkännande;
- en Fortnox-resurs ändras manuellt efter överföringen;
- avstämningen hittar en post som aldrig kom in i flödet.
För varje scenario ska teamet kunna svara på vilket av de fyra kvittona som finns, vilken handling som är säker och vem som äger nästa beslut. Om svaret kräver att en utvecklare tolkar råa loggar är undantagsarbetsytan inte klar.
Begränsningar och ansvar
API, villkor och funktioner kan förändras. Fortnoxs utvecklaravtal anger att API:t kan uppdateras och att integratören behöver testa efter ändringar; kontrollera därför aktuell teknisk dokumentation och avtalsversion före implementation (Fortnoxs utvecklaravtal). Bedöm också personuppgifter, loggning, lagring, åtkomst, backup och incidenthantering utifrån er miljö.
Ramverket avgör inte hur en affärshändelse ska bokföras, vilka verifikationer som krävs eller hur moms och skatt ska behandlas. Låt redovisningsansvarig definiera de verksamhetsregler och avstämningar som integrationen ska verkställa och synliggöra.
Källor
- Fortnox – utvecklaravtal
- Zapier – Ways to make API requests in Zapier
- Zapier – Send webhooks in Zap workflows
- n8n – HTTP Request node
Vanliga frågor
Vad är viktigast i en Fortnox-integration?
Att kunna skilja på godkänd affärshändelse, begärd överföring, bekräftad Fortnox-resurs och avstämt resultat. Varje steg behöver stabil identitet och bevis. Då går det att hantera dubbletter och okända resultat utan att anta att ett grönt API-anrop betyder att hela bokföringen är korrekt.
Kan man integrera Fortnox med Zapier?
Zapier kan göra generella API-anrop och skicka webhooks, men den praktiska lösningen beror på aktuell Zapier-funktionalitet, åtkomstmodell och ert integrationsfall. Kontrollera dagens produktstöd och bygg inte en skrivande integration utan dubblettskydd, säker credential-hantering, undantagsägare och avstämning.
Kan man integrera Fortnox med n8n?
n8n har en generell HTTP Request-node för REST-API:er. Det kan användas som en byggsten mot Fortnox API, men det löser inte autentisering, credential-livscykel, dubbletter, belastningsgränser, drift eller redovisningsregler automatiskt. De delarna behöver en uttrycklig design och en ansvarig ägare.
Hur undviker man dubbletter i Fortnox?
Använd ett stabilt käll-id och operations-id, spara Fortnox-referensen och kontrollera målstatus innan ett okänt resultat försöks igen. Behandla duplicerade händelser som samma avsikt. Exakt strategi måste anpassas till den Fortnox-resurs och de garantier som det aktuella API-anropet faktiskt har.
Är ett lyckat Fortnox API-anrop samma sak som korrekt bokföring?
Nej. Ett lyckat svar bekräftar att API:t behandlade den aktuella begäran enligt sitt kontrakt. Korrekt bokföring beror också på underlag, konton, regler, sammanhang och avstämning. Låt redovisningsansvarig definiera vad som ska kontrolleras och använd API-svaret som ett av flera kvitton.
Nästa steg: rita gränsen före integrationen
Välj en enda händelse som idag förs över till Fortnox. Skriv ner käll-id, förvalidering, operations-id, förväntad Fortnox-referens, okända utfall, undantagsägare och avstämningsregel. Använd sedan verktyget för processkartläggning för att beskriva nuläget och överlämningarna.
Om du vill resonera om en konkret Fortnox-integration kan du kontakta mig via e-post med den händelse som oftast kräver manuell rättning. Då går det att avgränsa ett test utan att låtsas att transportverktyget löser bokföringsansvaret.