De flesta växande bolag har redan systemen de behöver: ett bokföringsprogram, en e-handelsplattform, ett CRM och kanske ett lager- eller lönesystem. Problemet är att de inte pratar med varandra. Någon kopierar ordrar manuellt, kundregistret finns i tre versioner och fakturorna matas in för hand. En integration löser detta genom att låta systemen utbyta data automatiskt – men det är ett riktigt mjukvaruprojekt, inte en knapp man slår på.

Vad ett integrationsprojekt faktiskt innebär

En integration kopplar ihop två eller flera system så att data flödar mellan dem utan manuellt arbete. Det låter enkelt, men kärnan i arbetet är sällan tekniken i sig – det är att komma överens om vad data betyder. Vad är en kund i e-handeln jämfört med en kund i bokföringen? När räknas en order som klar nog att bli en faktura? Vilket system äger sanningen om en artikels pris?

Ett typiskt projekt har fyra faser: kartläggning av flöden och datamodeller, val av integrationsmönster, byggande och testning mot leverantörernas sandboxmiljöer, samt drift med övervakning. Den första fasen är ofta den viktigaste och mest underskattade. Att rita upp exakt vilka fält som ska mappas mellan systemen – och vad som händer när de inte stämmer – avgör om projektet blir stabilt eller en källa till ständiga buggar.

API:er: grunden för all integration

Ett API (Application Programming Interface) är systemets dörr utåt. De flesta moderna affärssystem erbjuder ett REST-API där du hämtar och skickar data över HTTP. För svenska bolag är Fortnox och Visma de tunga aktörerna.

Fortnox

Fortnox erbjuder ett REST-API (version 3) och använder OAuth2 Authorization Code Flow för autentisering. Du registrerar din integration i Fortnox utvecklarportal och får ett Client ID och Client Secret. Kunden godkänner själv vilka behörigheter (scopes) din integration ska ha. Det är värt att notera att den auktoriseringskod du får i flödet bara är giltig i tio minuter och kan användas en enda gång för att hämta access-token – ett vanligt nybörjarfel är att inte hantera token-förnyelsen robust.

Visma – numera Spiris

Här finns en namnförvirring att vara medveten om 2026: Visma Spcs har bytt namn till Spiris, och den svenska produkten som hette Visma eEkonomi heter nu Bokföring & Fakturering. Det viktiga för dig som integrerar: API:et är oförändrat. Visma eAccounting, eEkonomi, Spiris och Bokföring & Fakturering pekar mot samma API på eaccountingapi.vismaonline.com. Har du redan en integration behöver du inte ändra någon kod – men dokumentation och avtalstexter kan se olika ut beroende på när de skrevs.

Visma-API:et är REST-baserat, använder OAuth 2.0 med scopes och en sandbox med testbolag. Access-token är giltig i 60 minuter, vilket gör att korrekt hantering av refresh-token är obligatorisk för varje ansluten kund. API:et har inbyggt stöd för svenska specialiteter som ROT/RUT-fakturor och BAS-kontoplanen.

Webhooks: när du inte vill fråga hela tiden

Det finns två sätt att hålla system synkade. Det första är polling – du frågar API:et med jämna mellanrum: ”finns det några nya ordrar?”. Det är enkelt och fungerar mot vilket API som helst, men ger fördröjningar och en massa onödiga anrop. Det andra är webhooks – systemet ringer upp dig när något händer. När en order skapas skickar e-handeln ett HTTP-anrop till en URL du anger, nästan i realtid.

Fortnox stödjer webhooks för vissa objekt, framför allt kunder och fakturor. För många andra objekt – som leverantörsfakturor, verifikat och betalningar – finns inget native webhook-stöd, och då måste du falla tillbaka på polling. Det är en konkret begränsning att designa runt, inte en detalj att upptäcka i drift.

Webhooks är opålitliga – och det är meningen

Den enskilt viktigaste insikten om webhooks: ingen leverantör garanterar att en händelse levereras exakt en gång. Alla seriösa leverantörer kör minst-en-gång-leverans (at-least-once). Det betyder att din mottagare förr eller senare får samma händelse två gånger – och måste hantera det utan att skapa dubbla fakturor eller dubbla utskick.

Lösningen heter idempotens: samma indata ska ge samma resultat även om det kommer två gånger. I praktiken beräknar du en unik nyckel för varje händelse, kollar om du redan behandlat den, och applicerar bara ändringen om den är ny. Idempotens är inte en bonusfunktion – det är den bärande väggen i varje produktionsklar webhook-integration.

Lika viktigt är retries. Om din endpoint svarar med en felkod eller inte svarar alls, försöker leverantören igen med exponentiell backoff – ofta över timmar. Svarar du inte efter alla försök kan händelsen tappas helt. Därför är det rekommenderade mönstret 2026 en hybrid: webhooks som primär realtidskanal, kompletterat med periodisk polling som skyddsnät för att fånga händelser som webhooks missade vid driftstörningar.

Vanliga integrationsmönster

  • Order-till-faktura: en order i e-handeln (t.ex. Shopify eller WooCommerce) blir automatiskt en faktura eller ett verifikat i Fortnox eller Visma. Det vanligaste och mest värdeskapande flödet.
  • Kund- och artikelsynk: kunder och produkter hålls i synk mellan CRM, e-handel och bokföring så att samma kund inte finns i fem versioner.
  • Lagersaldo: saldon uppdateras mellan lager- och e-handelssystem för att undvika översäljning.
  • Betalmatchning: betalningar från betalleverantör matchas mot fakturor och bokförs.

De flesta projekt kan byggas antingen som en skräddarsydd integration eller via en iPaaS-plattform (integration platform as a service) som hanterar autentisering och köer åt dig. Skräddarsytt ger full kontroll och passar komplexa, affärskritiska flöden; en plattform går snabbare för standardiserade kopplingar men kostar i flexibilitet och löpande avgifter.

Datakvalitet avgör om det håller

En integration är aldrig bättre än datan den flyttar. De flesta haverier handlar inte om kod, utan om data: dubbletter, organisationsnummer i fel format, valutor som inte matchar, momssatser som tolkas olika. Innan du kopplar ihop systemen behöver du bestämma vilket system som är källan till sanningen för varje datatyp – och vad som ska hända när data inte validerar.

Bygg in tre saker från start: validering som stoppar trasig data vid dörren, loggning så att varje händelse kan spåras, och larm när något fastnar. En tyst integration som slutat fungera är farligare än ingen integration alls, eftersom man slutar dubbelkolla manuellt och upptäcker felet först när bokslutet inte stämmer.

Vad det kostar – och vad priset beror på

Det finns inget standardpris för en integration, eftersom spannet är enormt. Priset styrs av hur många system som kopplas ihop, hur väl deras API:er stödjer det du vill göra, datavolymerna, hur mycket datatvätt som krävs och om du behöver realtid via webhooks eller klarar dig med nattlig synk. En enkel order-till-faktura mot ett väldokumenterat API är ett helt annat projekt än en synk mellan fem system med smutsig historisk data.

Vill du ha en uppskattning för just ert flöde är det enklast att beskriva systemen och behoven i offertkalkylatorn – då får ni en bild av omfattningen utan gissningar.

ZORC bygger integrationen som håller

Vi har kopplat ihop Fortnox, Visma/Spiris, e-handel och CRM för bolag som tröttnat på manuellt dubbelarbete – med idempotens, övervakning och hybrid mellan webhooks och polling så att det faktiskt fungerar i drift, inte bara i demo. Berätta vad ni vill koppla ihop via kontakt, så hittar vi rätt ansats för era system.