Visma API: vilket av dem är det du faktiskt behöver?

Söker du på "Visma API" får du träffar för minst fyra olika gränssnitt som inte har något gemensamt utöver namnet. Det här är den uppdelning som avgör vilket spår du hamnar i.

För svenska mindre bolag som bokför och fakturerar är svaret nästan alltid Spiris. För bolag som kör ett fullt affärssystem är det Visma.net ERP. De två delar inte OAuth-flöde, bas-URL, scopes eller tenant-modell, så en integration mot det ena ger dig ingenting mot det andra.

Den enskilt vanligaste källan till förvirring just nu är namnbytet. Visma eEkonomi ingår numera i produktfamiljen Spiris, men bytet har inte gått hela vägen genom tekniken. Dokumentationen och värdnamnen använder fortfarande eAccounting-namnet, medan det kundvända varumärket är Spiris.

I praktiken innebär det att du behöver kunna båda namnen för att hitta rätt. API:ets bas-URL är https://eaccountingapi.vismaonline.com/v2, medan kunden loggar in på eaccounting.vismaonline.com och pratar om Spiris. Söker du bara på det ena namnet missar du halva dokumentationen.

API-ytan är stor. Vid vår genomgång av den publika OpenAPI-specifikationen innehöll 274 sökvägar och 228 operationer i OpenAPI 3.0.4-format, vilket är i samma storleksordning som Fortnox och betyder att du inte kommer att täcka allt i en första version.

Spiris/eAccounting använder authorization code med refresh token. Auktorisering sker mot identity.vismaonline.com/connect/authorize och tokens hämtas från identity.vismaonline.com/connect/token. Access-token gäller i 3 600 sekunder.

Refresh-token beskrivs som giltig i två år, men med ett förbehåll som är lätt att förbise: den slutar gälla när användaren byter lösenord. Bygger du för byråer eller andra miljöer med lösenordspolicyer kommer det att hända, och din integration behöver hantera det som ett normalt tillstånd som kräver ny inloggning — inte som ett fel.

Visma.net ERP går en helt annan väg. Autentiseringen sker genom Visma Connect, Vismas gemensamma identitetslager, där en service-integration använder client credentials mot connect.visma.com/connect/token tillsammans med ett tenant_id som pekar ut vilket bolag anropet gäller. Applikationen behöver godkännas av en tenant-administratör innan den får användas, vilket är ett steg som tar kalendertid och bör läggas in i planeringen tidigt.

Den dokumenterade gränsen för eAccounting är 600 anrop per minut, räknat per klient och per endpoint. Att gränsen är per endpoint och inte bara per klient är värt att notera: den är mer generös än den först låter för en integration som sprider anropen över olika resurser, och snålare än den låter för en som hamrar på en enda.

Överskrids gränsen svarar API:et med HTTP 429 och eAccounting-felkoden 4010. Felsvaren innehåller tre fält som är värda att spara: ErrorCode, DeveloperErrorMessage och ErrorId. Spara särskilt ErrorId i era loggar — det är den referens Vismas support behöver för att kunna spåra ett enskilt anrop, och utan den blir supportärendet en gissningslek.

Övriga felklasser att vänta sig är valideringsfel, saknade resurser, saknade scopes, otillräckliga behörigheter, inaktiva bolag och fel som beror på vilken produktvariant eller modul kunden har. Den sista kategorin är särskilt lömsk eftersom samma kod fungerar hos en kund och inte hos nästa.

Åtkomst börjar med registrering i Spiris partnerprogram, som ger klientuppgifter och ett sandbox-bolag att bygga mot. Riktningen mellan miljöerna är asymmetrisk och värd att förstå innan du planerar: en produktionsklient kan nå sandbox, men en sandbox-klient kan inte nå produktion.

Produktionsåtkomst kräver att du kontaktar Vismas API-support efter att applikationen är byggd. Distribution till kunder är ytterligare en separat process — kunden aktiverar tillägget Integration inne i Bokföring & Fakturering innan din integration kan väljas. API-åtkomst och marknadsplats­åtkomst är alltså två olika grindar, och båda tar tid.

Nordsynks lokala utvecklingsmiljö har redan sandboxregistrering och klientuppgifter för Spiris. De värdena är privata och är inte ett bevis på produktionsbehörighet. Redirect URI måste fortfarande godkännas och konfigureras för rätt miljö, och produktionsåtkomst samt publicering i Spiris integrationskatalog är externa godkännandesteg.

En del av dem som söker efter Vismas API vill egentligen inte bygga en integration. De vill nå sin bokföring från ChatGPT eller Claude och letar efter en MCP-server — Model Context Protocol, standarden som låter en AI-klient anropa ett system själv.

Spiris har en egen beta-MCP-server — se Spiris officiella MCP-dokumentation. Nordsynk är ett separat lager: vår MCP-server binder varje användare till uttryckligt valda bolag och leverantörer och lägger till skrivgodkännanden, revisionsspår, support och återställning. Nordsynk ska därför inte beskrivas som den enda vägen till Spiris data eller som en ersättning för Spiris egen MCP-server.

Om du bygger själv är erfarenheten från vår Fortnox-implementation att arbetsflöden är svårare än endpoints. Att exponera 228 operationer för en språkmodell gör den inte kompetent — den behöver namngivna arbetsflöden för det som API:et modellerar dåligt, och den behöver hindras från att skriva utan att en människa först ser exakt vad som kommer att ändras.