Vad är en API-integration?
En API-integration är en koppling mellan två system som utbyter information automatiskt via systemens API:er. Det ena systemet skickar en förfrågan, det andra svarar, och informationen förs över utan att någon behöver exportera en fil eller mata in samma uppgifter en gång till.
Det är idag den vanligaste metoden för systemintegration, och skälet är enkelt. Nästan alla system som byggts det senaste decenniet levereras med ett API som primär integrationsväg. För molntjänster är det i praktiken alltid fallet, och samma sak gäller de flesta moderna affärssystem, CRM-system och e-handelsplattformar.
I praktiken handlar det om att systemen ställer frågor till varandra och agerar på svaren. Integrationen frågar webbutiken vilka ordrar som tillkommit, får en strukturerad lista tillbaka, översätter uppgifterna till det format affärssystemet förväntar sig och skapar ordern där. Hela utbytet tar sekunder och sker utan att någon människa är inblandad.
Vad som utbyts styrs av verksamheten snarare än av tekniken. Ordrar, kunduppgifter, artiklar, prislistor, lagersaldon, fakturaunderlag och leveransbesked är de vanligaste, men i princip allt som ett system kan visa på skärmen kan också nås via ett API, förutsatt att leverantören valt att exponera det.
Poängen med metoden är kombinationen av hastighet och riktning. Informationen kan gå över inom sekunder i stället för att vänta på nästa manuella körning, och den kan gå åt båda hållen. Affärssystemet kan inte bara ta emot ordern utan också skicka tillbaka ordernumret, fråga en transportör om fraktpriser eller be en extern tjänst bedöma en kunds kreditvärdighet. Det är den dubbelriktade förmågan som skiljer API från en filöverföring i modern förpackning.
Skillnaden mellan ett API och en API-integration
Det här är den vanligaste förvirringen i ämnet, och den är värd att reda ut ordentligt. Missförståndet kostar pengar, eftersom det påverkar hur ni bedömer både offerter och tidsplaner.
Ett API är ett gränssnitt. Det är en uppsättning regler för hur ett system kan kontaktas, vilka frågor som får ställas, i vilket format svaret kommer och vad som krävs för att få tillgång. API:et är alltså en möjlighet som systemleverantören tillhandahåller, ungefär som en dörr med ett lås och en beskrivning av vilka nycklar som fungerar. Dörren i sig flyttar ingenting.
En API-integration är det som faktiskt byggs. Det är lösningen som bestämmer vilka anrop som ska göras, när de ska göras, hur svaret ska tolkas, hur data ska översättas mellan systemens olika format och vad som ska hända när något går fel.
Skillnaden märks tydligast i vad det kostar. Att ett system har ett API säger ingenting om hur lång tid en integration tar att bygga. Två system kan båda ha utmärkta API:er och ändå kräva veckor av arbete, eftersom tiden går åt till annat än själva kommunikationen.
Ta ett orderflöde som exempel. Vad ska hända när en order saknar organisationsnummer? Ska den stoppas eller släppas igenom? När webbutiken skickar ett fraktpris men affärssystemet räknar frakt på sitt eget sätt, vilket gäller? Vad händer om samma order kommer in två gånger? Vem får veta när något fastnar? Ingen av de frågorna handlar om API:et. Alla måste besvaras innan integrationen kan tas i drift.
Ett API är alltså en förutsättning, inte en lösning. Den som får svaret ”ja, vårt system har API” har fått veta att det är möjligt, inte att det är gjort.
Praktiskt betyder det två saker inför ett projekt. Låt er inte lugnas av att alla inblandade system har API, eftersom det bara betyder att ingen dörr är låst. Och begär att en offert specificerar vilka flöden som ingår och hur undantagen ska hanteras, inte bara vilka system som ska kopplas ihop.
Vad ett API gör i praktiken
Enklast är att följa ett konkret fall.
En kund lägger en order i webbutiken. Affärssystemet behöver veta om den, men systemen är byggda av olika leverantörer och delar ingen databas. I stället anropar integrationen webbutikens API med en fråga om vilka ordrar som tillkommit sedan förra kontrollen. Webbutiken svarar med en strukturerad lista, oftast i formatet JSON, där varje order innehåller kundens uppgifter, artikelrader, priser och leveransadress.
Integrationen tolkar svaret och översätter det till den struktur affärssystemet förväntar sig. Datumformat justeras, artikelnummer matchas mot rätt artikel och kunden identifieras eller läggs upp som ny. Därefter görs ett nytt anrop, nu mot affärssystemets API, med instruktionen att skapa ordern. Affärssystemet svarar med ett ordernummer, som integrationen skickar tillbaka till webbutiken så att kunden kan följa sin beställning.
Fyra anrop, några sekunder, noll manuellt arbete. Det är hela idén.
Samma princip skalar till betydligt mer omfattande flöden. Samma order kan i nästa steg utlösa en lagerreservation, en fraktbokning hos transportören och en kreditkontroll mot en extern tjänst, alla via samma typ av anrop mot respektive systems API. Vad som händer i vilken ordning, och vad som ska ske om ett av stegen misslyckas, bestäms av integrationen.
Samtidigt är det värt att vara nykter med vad API:et faktiskt löser. Det hanterar kommunikationen mellan två system. Det gör ingenting åt vad som händer när svaret uteblir, när volymen växer över vad systemet klarar eller när ni har tolv sådana här kopplingar att hålla reda på. Den skillnaden återkommer vi till längre ned, eftersom den är avgörande för valet mellan att bygga enskilda integrationer och att samla dem i ett gemensamt lager.
Så fungerar en API-integration steg för steg
Bakom det som ser ut som en enkel överföring ligger fyra moment som alla måste fungera. Det är värt att förstå dem, av två skäl. Dels är det här merparten av kostnaden i ett integrationsprojekt uppstår, dels är det här det går sönder när något går sönder.
Anrop och svar
All kommunikation bygger på samma grundmönster: ett system ställer en fråga och ett annat svarar.
Anropet innehåller tre delar. Vad som efterfrågas, alltså vilken typ av information eller åtgärd det gäller. Vilka villkor som gäller, exempelvis att bara ordrar skapade efter en viss tidpunkt ska returneras. Och vem som frågar, i form av de uppgifter som styrker behörigheten.
Anropen delas in efter vad de gör. Att hämta befintlig information är en sak, att skapa något nytt en annan, att uppdatera något som redan finns en tredje och att ta bort en fjärde. Åtskillnaden är inte akademisk. Den avgör vilka behörigheter integrationen behöver, och den är skälet till att ett integrationskonto som bara ska läsa aldrig bör ha rätt att radera.
Svaret kommer i ett strukturerat format, i praktiken oftast JSON, som är läsbart även för en människa. Tillsammans med innehållet kommer en statuskod som talar om hur det gick. Framgång ser olika ut beroende på operation, medan fel delas upp i sådant som beror på den som frågar, exempelvis felaktig behörighet eller ofullständiga uppgifter, och sådant som beror på systemet som svarar, exempelvis driftstörning.
Den distinktionen är viktigare än den låter. Ett fel som beror på anropet blir inte bättre av att försökas igen, medan ett fel som beror på mottagaren ofta löser sig av sig självt inom några minuter. En integration som behandlar alla fel likadant kommer antingen att ge upp för tidigt eller att hamra på en förfrågan som aldrig kommer att gå igenom.
Det är också här skillnaden mellan en robust och en skör integration syns tydligast. Den sköra antar att svaret innehåller det den förväntar sig. Den robusta kontrollerar statuskoden först och agerar därefter.
Autentisering, hur systemen litar på varandra
Ett API släpper inte in vem som helst. Innan någon information utbyts måste det anropande systemet visa vem det är och att det har behörighet för åtgärden.
Den enklaste modellen är en API-nyckel, alltså en lång teckensträng som följer med varje anrop. Det fungerar, men är trubbigt. Nyckeln ger samma åtkomst oavsett sammanhang, den gäller tills någon aktivt byter ut den, och läcker den ut finns sällan något sätt att se vad som hunnit hända.
Vanligare i moderna system är OAuth, där integrationen inte skickar en permanent nyckel utan hämtar en tidsbegränsad token som förnyas automatiskt. Token kan dessutom begränsas till specifika behörigheter, så att en integration som bara ska läsa ordrar inte samtidigt kan ändra prislistor. Modellen kräver mer att sätta upp och ger märkbart bättre kontroll.
Oavsett modell finns tre saker att bestämma tidigt.
Integrationen ska ha ett eget konto i varje anslutet system, inte dela konto med en medarbetare. Annars blir loggarna oläsbara, och den dag personen slutar och kontot avaktiveras stannar flödet utan att någon förstår varför.
Kontot ska ha minsta möjliga behörighet för sin uppgift. Integrationskonton med administratörsrättigheter är en av de vanligaste svagheterna i annars välbyggda systemlandskap, just för att de sätts upp en gång och sedan aldrig ses över.
Och någon ska veta var nycklarna finns och hur de byts. Autentiseringsuppgifter som ligger i klartext i en konfigurationsfil, eller som bara den ursprungliga utvecklaren känner till, är ett problem som växer med tiden.
När personuppgifter passerar tillkommer krav utöver de tekniska, bland annat på personuppgiftsbiträdesavtal och på att bara nödvändiga fält förs över. Vi går igenom det i avsnittet om säkerhet och GDPR vid systemintegration.
Datatransformation mellan systemens format
Här ligger merparten av arbetet i en API-integration, och det är också den del som konsekvent underskattas i tidsplaner.
Två system beskriver sällan samma verklighet på samma sätt. Ett datum kan komma som 2026-08-23 från ett system och som 23/08/2026 från ett annat. En kund kan identifieras med organisationsnummer på ett ställe och med ett internt kundnummer på ett annat. Ett fält som heter kundnamn i webbutiken kan motsvaras av två separata fält för förnamn och efternamn i affärssystemet. Momssatser, valutakoder, enheter, betalningsvillkor och artikelnummer följer samma mönster.
Transformationen är den regeluppsättning som översätter mellan formaten, och den kallas ofta mappning. Fält för fält bestäms vad som motsvarar vad, och vad som ska hända när det inte finns någon självklar motsvarighet.
Det är i det sista som tiden går. En del regler är triviala, som att skriva om ett datumformat. Andra kräver ett verksamhetsbeslut. Om webbutiken tillåter fritext i ett fält som affärssystemet kräver ska matcha en fördefinierad lista, vad gör integrationen med det som inte matchar? Om en artikel finns i webbutiken men inte i affärssystemet, ska ordern stoppas eller ska artikeln läggas upp automatiskt? Om kunden angett en leveransadress i ett format som transportörens system inte accepterar, vem får veta?
Den typen av frågor kan integrationsleverantören inte svara på. De kräver någon som förstår verksamheten, och de behöver besvaras i designfasen snarare än under utveckling. Det är också det vanligaste skälet till att integrationsprojekt drar ut på tiden: inte tekniken, utan att rätt person i verksamheten inte hunnit ta ställning.
En sista sak som lönar sig långsiktigt: dokumentera besluten löpande och versionshantera dem. Varför ett fält mappas på ett visst sätt är trivialt när beslutet fattas och närmast omöjligt att rekonstruera två år senare.
Vad som händer när något går fel
Det normala fallet är enkelt att bygga. Det är undantagen som avgör om integrationen håller.
Mottagande system kan vara nere för underhåll. Nätverket kan tappa förbindelsen mitt i ett anrop. En post kan sakna uppgifter som mottagaren kräver. Samma order kan komma in två gånger. Volymen kan plötsligt vara tio gånger högre än en vanlig tisdag.
En genomtänkt integration har svar på samtliga. Anrop som misslyckas på grund av tillfälliga fel görs om automatiskt, med ökande fördröjning mellan försöken så att ett system som redan är belastat inte belastas ytterligare. Poster som inte går att behandla parkeras i en felkö där de kan åtgärdas, i stället för att försvinna tyst. Och någon behöver få veta att det hänt, vilket förutsätter övervakning och larm.
Det sista är avgörande och förbises ofta. Den farligaste typen av fel är inte det som stoppar flödet, eftersom någon då märker det inom kort. Det farliga är det som ser ut att fungera. En integration som hämtar första sidan av tio, eller som tolkar ett felmeddelande som att inget fanns att hämta, kommer att rapportera framgång varje gång. Problemet upptäcks först när någon undrar var ordrarna tog vägen, och då har det oftast pågått ett tag.
Här blir skillnaden mellan en enskild koppling och ett gemensamt lager konkret för första gången. Köhantering, återförsök, felkö, övervakning och larm behöver byggas i det första fallet och finns redan i det andra. Bygger ni tre integrationer bygger ni samma sak tre gånger.
Olika typer av API:er
Alla API:er fungerar inte likadant. Skillnaderna handlar om hur anropen struktureras, vilket format svaren kommer i och hur mycket ni kan styra över vad som hämtas.
I praktiken behöver ni sällan välja. Typen bestäms av vilka system ni har, inte av vad ni föredrar. Däremot är det värt att veta vad ni möter, eftersom det påverkar både tidsåtgång och vilken kompetens som krävs.
REST
REST är den dominerande modellen och det ni möter i de allra flesta moderna system. Varje resurs, exempelvis en order eller en kund, har en egen adress, och olika operationer utförs genom olika metoder mot den adressen. Formatet är i princip fritt, men i praktiken kommer svaren nästan alltid i JSON.
Fördelen är enkelheten. Ett REST-API går att prova med enkla verktyg, såsom Postman, dokumentationen är oftast begriplig och de flesta utvecklare kan arbeta med det utan särskild upplärning.
Begränsningen är att ni bara får det som API:et bestämt att ni ska få. Behöver ni en order med kundens fullständiga uppgifter och artiklarnas lagersaldon kan det kräva tre separata anrop, ett för ordern, ett för kunden och ett för artiklarna. Vid låga volymer är det oproblematiskt. Vid höga volymer blir det snabbt en fråga om anropsgränser.
SOAP
SOAP är äldre, mer formell och bygger på XML i stället för JSON. Anropen är omfångsrikare och strukturen är strikt definierad i en separat beskrivningsfil, vilket gör att avvikelser upptäcks direkt.
Modellen känns tungrodd i jämförelse med REST, men den har verkliga fördelar i miljöer med höga krav på formell struktur och transaktionshantering. Framför allt möter ni SOAP i etablerade affärssystem, där gränssnittet ofta byggdes innan REST slog igenom och lever kvar av kompatibilitetsskäl.
Att ett API är SOAP-baserat är alltså inget varningstecken. Det innebär i regel något mer arbete och att den som bygger behöver ha gjort det förut, men funktionsmässigt är det ofta det mest kompletta gränssnitt en leverantör erbjuder.
GraphQL
GraphQL vänder på logiken. I stället för att API:et bestämmer vad ett svar innehåller beskriver den som frågar exakt vilka fält som ska returneras, och får precis det tillbaka.
Det adresserar båda begränsningarna med REST på en gång. Svaren innehåller inget överflödigt, och information som annars hade krävt tre separata anrop kan hämtas i ett. Vid stora datamängder och höga volymer är det en märkbar skillnad, både i hastighet och i förbrukade anrop.
Modellen har samtidigt egna svagheter. Eftersom den som frågar själv sätter ihop sin fråga går det att formulera anrop som belastar systemet betydligt hårdare än avsett, vilket gör att leverantörer ofta mäter förbrukning i kostnadspoäng i stället för i antal anrop. Komplexiteten är dessutom högre, både att bygga och att felsöka, och kompetensen är mindre spridd än för REST.
Var ni möter GraphQL skiljer sig kraftigt mellan systemtyper. I affärssystemsvärlden är det fortfarande ovanligt, där dominerar REST och SOAP. Inom e-handel går utvecklingen åt andra hållet. Shopify klassade sitt REST Admin API som ett äldre API i oktober 2024 och kräver sedan april 2025 att alla nya appar och integrationer byggs med GraphQL, med beskedet att det blir det enda API som stöds på sikt.
Praktiskt innebär det att ett och samma orderflöde mycket väl kan ha GraphQL i ena änden och SOAP i den andra. Det är inte ett problem i sig, men det är ett tydligt exempel på varför integrationsarbete sällan handlar om att välja en teknik.
Webhooks
Webhooks är inte riktigt en API-typ utan en omvänd riktning. I stället för att ni frågar systemet om något har hänt meddelar systemet er när det händer.
Ni registrerar en adress hos leverantören, och när en händelse inträffar, exempelvis att en order skapas eller en betalning genomförs, skickar systemet automatiskt informationen dit. Det ger färsk data utan att ni behöver fråga hela tiden, och det belastar båda systemen mindre.
Baksidan är att ni måste kunna ta emot. Adressen behöver vara nåbar utifrån, den behöver svara snabbt, och den behöver kvittera att meddelandet tagits emot. Är er sida nere när meddelandet skickas är det inte givet att leverantören försöker igen, och vissa leverantörer försöker bara ett fåtal gånger innan de ger upp.
Webhooks kräver därför i praktiken en mottagande infrastruktur med kö, kvittens och möjlighet att fånga upp det som missats. Det är mer än ett enkelt skript, och det är en av de tydligaste punkterna där en plattform gör verklig skillnad.
Vilken typ ni möter i praktiken
I ett verkligt systemlandskap möter ni flera av dem samtidigt, ofta inom ett och samma flöde. Det är helt normalt, och det är ett av skälen till att kopplingarna blir svåra att överblicka när de byggs var för sig. Varje typ har sin egen autentisering, sin egen felhantering och sitt eget sätt att gå sönder.
Hämta eller bli meddelad, polling mot webhooks
Utöver vilken typ av API som används finns ett vägval som påverkar både kostnad och hur färsk informationen blir. Ska integrationen fråga systemet om något hänt, eller ska systemet berätta för er?
Polling innebär att integrationen frågar med jämna mellanrum. Var femte minut, varje timme eller varje natt, beroende på behov. Modellen är enkel att bygga, fungerar mot i princip alla API:er och är lätt att felsöka, eftersom varje körning är en avgränsad enhet med tydlig start och tydligt slut.
Priset är dubbelt. Informationen är aldrig färskare än intervallet, och de allra flesta anrop går till spillo. Frågar ni var femte minut och det kommer ordrar tio gånger om dagen svarar API:et att inget nytt finns närmare trehundra gånger dagligen. Det kostar anrop, och anrop är i regel en begränsad resurs.
Webhooks vänder på riktningen och löser båda problemen. Ni får informationen i samma stund som händelsen inträffar, och bara när något faktiskt hänt. I gengäld flyttas ansvaret till er sida. Adressen måste vara nåbar och svara snabbt, mottagandet måste kvitteras, och ni behöver hantera det fall då ett meddelande går förlorat.
I praktiken används de ofta tillsammans, och det är oftast den bästa lösningen. Webhooks driver flödet i normalfallet, och en polling som körs en gång per dygn fångar upp det som eventuellt missats. Kombinationen ger både snabbhet och tillförlitlighet, men den förutsätter en infrastruktur som klarar båda och som kan avgöra vad som redan behandlats.
Tumregeln är densamma som för batch och realtid i stort: flöden som någon väntar på ska gå direkt, medan flöden som ingen väntar på kan hämtas enligt schema. En order som kunden följer hör till den första kategorin. En nattlig uppdatering av artikelregistret hör till den andra.
Vad som gör ett API bra eller dåligt
Att ett system har ett API säger nästan ingenting om hur lätt det är att integrera med. Kvaliteten varierar enormt mellan leverantörer, och skillnaden slår igenom direkt i både tidsåtgång och kostnad.
Det här är därför en fråga att ställa innan ni väljer system, inte efter. Ett affärssystem som passar verksamheten perfekt men har ett halvfärdigt API kommer att kosta er i varje integrationsprojekt under hela systemets livslängd, och den kostnaden syns aldrig i offerten.
Fem saker avgör, och samtliga går att kontrollera i förväg.
Dokumentationen
Bra dokumentation beskriver varje anrop, varje fält, varje statuskod och varje felmeddelande, med exempel som går att kopiera och prova. Den anger vilka fält som är obligatoriska, vilka format som accepteras och hur systemet beter sig i gränsfall.
Dålig dokumentation är antingen ofullständig eller inaktuell, och det senare är betydligt värre. Ett API som beter sig annorlunda än dokumentationen påstår tvingar fram utveckling genom gissning och testning, och den tiden finns aldrig med i någon tidsplan.
Ett snabbt test som ni kan göra själva: leta upp dokumentationen innan ni skriver under något. Är den publik, sökbar och full av exempel är det ett gott tecken, både om API:et och om leverantörens inställning till integration. Krävs det inloggning, kundnummer eller ett supportärende för att ens få se den säger det något om vad förvaltningen kommer att kosta.
Täcker API:et det ni faktiskt behöver?
Många API:er täcker bara en del av systemets funktionalitet. Det som går att göra i användargränssnittet går inte alltid att göra via API:et, och skillnaden är sällan dokumenterad på ett ställe.
Det vanligaste mönstret är att läsning fungerar utmärkt medan skrivning är begränsad. Ni kan hämta ordrar men inte skapa dem, eller skapa dem men inte sätta just de fält ni behöver. Kundanpassade fält är särskilt ofta exponerade halvvägs, vilket är obekvämt eftersom det ofta är där er faktiska affärslogik sitter.
Gå därför igenom era verkliga flöden mot API-dokumentationen innan projektet startar, fält för fält. Att upptäcka en lucka i designfasen är en fråga om att välja en annan väg. Att upptäcka den under utveckling är en fråga om ett omtag, och ibland om att en del av flödet får förbli manuellt.
Anropsgränser och prestanda
Nästan alla API:er begränsar hur mycket de får användas. Begränsningen kan gälla antalet anrop per minut eller per dygn, hur många anrop som får pågå samtidigt, eller hur mycket data ett enskilt svar får innehålla.
NetSuite är ett tydligt exempel. Där finns både ett tak för samtidiga anrop och gränser per tidsenhet, och utrymmet delas mellan samtliga integrationer mot samma konto. Det innebär att en ny integration kan påverka en befintlig, vilket är lätt att missa när kopplingarna byggs var för sig av olika leverantörer vid olika tillfällen.
Ta reda på gränserna tidigt och jämför dem mot era volymer, med marginal för toppar. Ett API som klarar dagens flöde utan problem kan bli en flaskhals när högsäsongen slår till, när ni öppnar en ny försäljningskanal eller när ytterligare en integration läggs till på samma konto.
Fråga också hur gränserna hanteras. Vissa system köar anrop som överskrider taket, andra avvisar dem rakt av. Skillnaden avgör hur integrationen behöver byggas.
Finns det en testmiljö?
En separat testmiljö, ofta kallad sandbox, gör det möjligt att bygga och prova utan att röra skarp data. Utan en sådan tvingas ni antingen testa i produktion eller bygga blint fram till driftsättning, och båda alternativen är dåliga.
Fråga också hur testmiljön förhåller sig till produktion. En sandbox som saknar era konfigurationer, kundanpassade fält och verkliga artikelregister ger falsk trygghet, eftersom integrationen kan fungera perfekt i test och gå sönder direkt i drift.
Ta reda på om miljön uppdateras med kopior från produktion, hur ofta det sker och vad det kostar. Och om ni kopierar produktionsdata till test, kom ihåg att skarpa personuppgifter då hamnar i en miljö med lägre säkerhet och bredare åtkomst. Anonymiserade eller syntetiska testdata är att föredra.
Hur hanteras nya versioner?
API:er förändras. Frågan är inte om utan hur ni får veta, och hur lång tid ni får på er.
Bra leverantörer versionerar sina API:er, låter äldre versioner leva kvar parallellt en tid och meddelar i god tid när något ska tas ur bruk. Sämre leverantörer ändrar utan förvarning, och då upptäcker ni det när flödet slutar fungera, i värsta fall utan att någon larmar.
Ta reda på tre saker. Har leverantören en officiell livscykel för sina API-versioner? Hur lång framförhållning ger de innan en version tas ur bruk? Och var kommuniceras förändringar, alltså finns det en förändringslogg eller ett utskick att prenumerera på?
Svaren avgör hur mycket löpande underhåll integrationen kommer att kräva, och därmed en betydande del av totalkostnaden över tid.
Sju frågor att ställa till systemleverantören
Ta med de här in i nästa leverantörsmöte, gärna innan avtal skrivs.
- Är API-dokumentationen publikt tillgänglig, och kan vi få se den nu?
- Täcker API:et samtliga fält och funktioner vi behöver, inklusive våra kundanpassade fält?
- Vilka anropsgränser gäller, och delas de mellan flera integrationer på samma konto?
- Finns en testmiljö, och speglar den vår produktionskonfiguration?
- Hur versioneras API:et, och hur lång framförhållning ger ni innan en version tas ur bruk?
- Stöds webhooks, eller måste vi hämta all information genom att fråga?
- Ingår API-åtkomsten i licensen, eller kostar den extra?
Den sista är värd att ställa explicit och tidigt. Alla systemleverantörer ser inte integration som något önskvärt, eftersom öppenhet gör det enklare för kunden att byta ut delar av landskapet. Integrationsmöjligheter kan därför vara begränsade eller prissatta separat, och det är betydligt lättare att förhandla om innan avtalet är påskrivet.
Vanliga problem i API-integrationer
De här dyker upp i projekt efter projekt. Ingen av dem är särskilt svår att hantera om den planeras för, och samtliga är dyra att upptäcka i produktion.
Strypning när gränserna nås
När en integration överskrider API:ets anropsgränser slutar systemet svara normalt och returnerar i stället ett felmeddelande om att gränsen nåtts.
Det farliga är hur lätt det felet misstolkas. En integration som inte förväntar sig situationen kan tolka svaret som att inget fanns att hämta och gå vidare som om allt vore normalt. Data uteblir utan att någon larmar.
Lösningen är att känna igen situationen, vänta och försöka igen med ökande fördröjning, samt att fördela anropen över tid i stället för att skicka allt på en gång. Det förutsätter i sin tur någon form av köhantering, eftersom de anrop som väntar måste ligga någonstans under tiden.
Paginering och stora datamängder
Ett API returnerar sällan tusentals poster i ett enda svar. I stället delas resultatet upp i sidor som måste hämtas en i taget, där svaret innehåller information om huruvida det finns mer att hämta.
Integrationer som inte hanterar det får bara första sidan. Det är särskilt lömskt eftersom allt ser ut att fungera, och eftersom problemet ofta uppstår först senare, när volymen vuxit förbi vad en enda sida rymmer. En integration som fungerat felfritt i två år kan alltså börja tappa poster utan att något ändrats i den.
Pagineringen behöver därför byggas in från början, med kontroll av att hämtningen faktiskt gått ända till slutet.
Dubbletter och varför idempotens spelar roll
Om ett anrop skickas och svaret uteblir vet den anropande sidan inte om mottagaren hann utföra åtgärden eller inte. Görs anropet om kan resultatet bli två identiska ordrar, två fakturor eller två lagerjusteringar.
Lösningen kallas idempotens och innebär att samma anrop kan göras flera gånger utan att resultatet ändras. Praktiskt sker det på två sätt. Antingen får varje anrop en unik identifierare som mottagaren känner igen och avvisar vid upprepning, eller så kontrollerar integrationen om posten redan finns innan den skapar en ny.
Det här är ett av de vanligaste skälen till dubbelposter i affärssystem, och det är helt undvikbart. Fråga uttryckligen hur det är löst, eftersom det sällan står i en offert.
När leverantören ändrar sitt API
Ett fält byter namn, ett svar får en ny struktur eller en operation tas ur bruk. Integrationen slutar fungera, och beroende på hur den är byggd märks det antingen omedelbart eller först när någon saknar informationen.
Skyddet är dubbelt. Dels bevakning av leverantörens förändringsmeddelanden, vilket förutsätter att någon faktiskt är utpekad att göra det. Dels en integration som larmar när svaren inte ser ut som förväntat, i stället för att tyst hoppa över det den inte känner igen.
När mottagande system inte svarar
Underhållsfönster, driftstörningar och nätverksproblem är oundvikliga. Frågan är vad som händer med de poster som skulle ha levererats under tiden.
Utan kö försvinner de, eller ligger kvar i källsystemet i väntan på att någon upptäcker att de inte kommit fram. Med kö ligger de ordnade och behandlas automatiskt när systemet är tillbaka.
Det är en av de mest grundläggande skillnaderna mellan en integration som är byggd för att fungera i drift och en som är byggd för att fungera vid demonstration.
Vad kostar en API-integration?
Kostnaden varierar kraftigt, och det som styr är sällan tekniken i sig.
En koppling mellan två moderna system med väldokumenterade API:er, där fälten motsvarar varandra hyfsat rakt av och flödet är enkelriktat, ligger i den billiga änden. Ett flöde som löper genom flera system, med mycket affärslogik, omfattande undantagshantering och ett äldre system någonstans i kedjan, ligger i den dyra.
Tre poster underskattas nästan alltid. Kartläggningen av vad som faktiskt ska hända i flödet tar tid och kräver personer från verksamheten, inte bara från IT. Datakvaliteten i källsystemet behöver ofta åtgärdas innan något kan flyttas, eftersom en integration sprider det som finns, inklusive dubbletter och inaktuella register. Och förvaltningen fortsätter så länge integrationen lever, eftersom API:er versioneras och verksamheter förändras.
Räkna därför alltid med två kostnader, en för att bygga och en löpande för att förvalta. Den andra är den som avgör totalkostnaden över tid, och det är också den som skiljer mest mellan att bygga enskilda kopplingar och att lägga dem i ett gemensamt lager.
Bygga själv eller använda en integrationsplattform?
Här ligger artikelns egentliga fråga. En API-integration går utmärkt att bygga som en fristående lösning, och för vissa behov är det rätt val. För andra blir det dyrt på ett sätt som inte syns förrän efter ett par år.
När en enskild integration räcker
Det räcker oftast när ni har en eller två kopplingar, när båda systemen är moderna och stabila, när flödet är enkelt och sällan förändras, och när ni har någon internt som både kan och hinner underhålla lösningen.
I den situationen är en skräddarsydd integration både snabbare och billigare att få på plats. Ni betalar inga plattformsavgifter, och lösningen gör exakt det ni behöver, varken mer eller mindre.
Det finns ingen anledning att komplicera något som är enkelt. Poängen är att veta när det slutar vara enkelt.
När antalet kopplingar tippar över
Problemet med enskilda API-integrationer är att de inte delar något med varandra. Varje koppling har egen autentisering, egen felhantering, egen loggning och egen livscykel. Löser ni återförsök i den första integrationen är det arbetet inte gjort i den andra.
Antalet växer dessutom snabbare än antalet system. Tre system som ska prata med varandra kräver upp till tre kopplingar, fem system upp till tio och åtta system upp till 28. När flera av dem går mot samma system, och det systemet en dag ska bytas ut, ska samtliga byggas om.
Brytpunkten går sällan vid ett bestämt antal, men signalerna är tydliga. Ingen har full överblick över vilka kopplingar som finns eller vad de gör. Ingen vågar stänga av något, eftersom konsekvenserna är okända. Det finns ingen gemensam bild av vad som körts och när. Och en till synes enkel förändring kräver att någon först återskapar förståelsen av hur allt hänger ihop.
Känner ni igen två eller fler av de punkterna har brytpunkten sannolikt redan passerats.
Vad en integrationsplattform tillför utöver själva anropet
Det här är kärnan, och det missförstås ofta: ett API löser kommunikationen mellan två system, men ingenting av det som omger den.
Köhantering och återförsök när ett system inte svarar. Schemaläggning och styrning av flödestakten mot anropsgränser. Felköer där poster som inte gick igenom kan hanteras i stället för att försvinna. Övervakning som visar vad som körs, när det körs och varför. Spårbarhet på enskilda poster när någon undrar var en order tog vägen. Versionshantering av flöden och regler.
Allt det ovanstående måste byggas i en fristående integration och finns redan i en integrationsplattform. Till det kommer återanvändbarheten. Nästa integration byggs med komponenter som redan är i drift och testade, vilket gör att den i regel blir billigare än den förra i stället för dyrare.
Den mest långsiktiga skillnaden handlar dock om var affärslogiken hamnar. Byggs valideringar, beräkningar och flödesregler in i den enskilda kopplingen försvinner de den dag systemet byts ut. Hålls de i ett eget lager, frikopplat från de anslutna systemen, behöver bara kopplingsskiktet mot det nya systemet skrivas om medan flödena lever kvar.
Det är skillnaden mellan att bygga en engångslösning och att bygga något som håller över flera systemgenerationer.
Vill ni gå djupare i hur en plattform fungerar, vad den innehåller och hur den skiljer sig från traditionella lösningar har vi en komplett guide: Vad är en integrationsplattform (iPaaS)?
Vanliga frågor om API-integrationer
Vad är skillnaden mellan ett API och en API-integration?
Ett API är gränssnittet som ett system tillhandahåller, alltså reglerna för hur det kan kontaktas. En API-integration är den lösning som faktiskt byggs med hjälp av det gränssnittet, med anrop, datatransformation, felhantering och regler för vad som ska hända i olika situationer. Att ett system har ett API betyder att integration är möjlig, inte att den är gjord.
Kan man integrera system som saknar API?
Ja, men på andra sätt. Vanliga alternativ är filbaserad överföring, direkt databasåtkomst eller standardiserade format som EDI. Lösningarna fungerar men är ofta mer ömtåliga och kräver mer underhåll, vilket påverkar både kostnad och tillförlitlighet över tid.
Behöver vi en egen utvecklare för att bygga API-integrationer?
Inte nödvändigtvis. Bygger ni fristående integrationer behöver någon kunna underhålla dem över tid, vilket antingen kräver egen kompetens eller ett löpande konsultavtal. Med en integrationsplattform ligger drift och förvaltning hos leverantören, och det ni behöver bidra med är kunskap om era egna processer och flöden.
Vad är skillnaden mellan API-integration och EDI?
API-integration används framför allt för att koppla ihop era egna system, medan EDI används för att utbyta standardiserade affärsdokument med externa parter som kunder, leverantörer och myndigheter. Kravet på EDI kommer ofta utifrån, exempelvis från en större kund eller genom lagstiftningen om elektronisk faktura vid offentlig upphandling.
Hur ofta går API-integrationer sönder?
Sällan av sig själva. De vanligaste orsakerna är att leverantören ändrat sitt API, att anropsgränser överskridits eller att ett anslutet system varit otillgängligt. Samtliga går att hantera genom bevakning, återförsök och övervakning, men det förutsätter att någon byggt in det från början och att någon är utpekad att följa upp.
Är API-integration säkert?
Ja, förutsatt att grunderna är på plats. Kommunikationen ska vara krypterad, autentiseringen ska ske med hanterade nycklar eller tokens, och varje integration ska ha ett eget konto med minsta möjliga behörighet. När personuppgifter passerar tillkommer krav på uppgiftsminimering och personuppgiftsbiträdesavtal med leverantören.
Hur lång tid tar det att bygga en API-integration?
Det avgörs sällan av utvecklingen. Det som styr är hur väl flödet är kartlagt från början, hur bra API:erna är i de inblandade systemen, vilken kvalitet data håller i källsystemet och hur snabbt rätt personer i verksamheten kan ta ställning till hur undantagen ska hanteras.
Den korta versionen
En API-integration kopplar ihop två system genom deras API:er, så att information utbyts automatiskt och i realtid. Själva API:et är bara gränssnittet, alltså möjligheten. Arbetet ligger i att mappa fälten, hantera undantagen och bestämma vad som ska ske när något går fel.
Kvaliteten på leverantörens API avgör mer än något annat vad det kommer att kosta. Kontrollera dokumentation, funktionstäckning, anropsgränser, testmiljö och versionshantering innan ni väljer system, inte efter, eftersom den kostnaden återkommer i varje integrationsprojekt under systemets hela livslängd.
Frågan om att bygga själv eller använda en integrationsplattform handlar inte om den första integrationen utan om den femte. Ett API löser kommunikationen mellan två system men inte köhantering, övervakning, spårbarhet eller förvaltning, och det som byggs in i en enskild koppling försvinner den dag systemet byts ut.
Ett bra första steg är att gå igenom era faktiska flöden mot leverantörernas API-dokumentation och se var luckorna finns. Vill ni ha hjälp att bedöma vad som är möjligt i ert systemlandskap är ni välkomna att boka en kostnadsfri och förutsättningslös demo, så går vi igenom förutsättningarna tillsammans.