En API-integration är en koppling som låter två system utbyta data och funktioner automatiskt, utan att en människa behöver flytta informationen manuellt. API står för Application Programming Interface och är i praktiken ett standardiserat kontrakt: "så här frågar du mig, och så här svarar jag". När din webbshop skickar ordern till bokföringen av sig själv, eller ditt CRM uppdateras när någon fyller i ett formulär, är det API-integrationer som gör jobbet.
Konkreta exempel du redan använder
API-integrationer är osynliga när de fungerar, men de finns överallt i en modern verksamhet:
- Betalningar. När en kund betalar med kort på din sajt pratar din plattform med Stripe, Klarna eller Swish via API. Beloppet dras, kvittot skapas och ordern markeras som betald, allt på några sekunder.
- CRM och marknadsföring. Ett formulär på webbplatsen skapar en kontakt i HubSpot, som i sin tur triggar ett välkomstmail. Tre system, noll manuellt arbete.
- Bokföring. Order och betalningar från e-handeln flödar in i Fortnox eller Visma som färdiga underlag, i stället för att någon sitter och stansar fakturor på fredagar.
- Streaming och media. En videoplattform hämtar titlar, undertexter och rättighetsinformation från flera källor via API och håller katalogen uppdaterad automatiskt.
Mönstret är detsamma i alla exemplen: data som annars skulle klippas och klistras mellan system flyttar sig själv, snabbare och utan slarvfel.
REST, GraphQL och webhooks, utan jargong
Tre begrepp dyker alltid upp i offerter och teknikdiskussioner. Du behöver inte kunna bygga dem, men det hjälper att veta vad de betyder.
REST är det vanligaste sättet att bygga API:er. Tänk på det som ett bibliotek med tydliga hyllor: varje typ av data har en egen adress, och du hämtar eller uppdaterar den med standardiserade kommandon. Enkelt, väldokumenterat och stött av i princip alla system.
GraphQL är ett nyare alternativ där den som frågar själv bestämmer exakt vilka fält den vill ha tillbaka. Det är som att beställa en skräddarsydd rapport i stället för att få hela pärmen. Praktiskt när appar behöver mycket data från flera håll i en enda fråga.
Webhooks vänder på flödet. I stället för att ditt system frågar "har det hänt något nytt?" var femte minut, säger det andra systemet till direkt när något händer: "en betalning kom just in". Det är skillnaden mellan att gå till brevlådan varje timme och att ha en dörrklocka.
De flesta verkliga integrationer kombinerar dessa: REST eller GraphQL för att hämta och skriva data, webhooks för att reagera på händelser.
Bygga själv, integrationsplattform eller byrå?
Det finns tre vägar till en färdig integration, och rätt val beror på hur affärskritisk kopplingen är.
Bygga själv passar när du har egna utvecklare och integrationen ligger nära kärnverksamheten. Du får full kontroll och exakt det beteende du vill ha, men du äger också allt underhåll och all felsökning.
Integrationsplattformar som Zapier och Make låter icke-utvecklare koppla ihop standardsystem på minuter. Utmärkt för enkla flöden med låg volym, som "nytt formulärsvar blir en rad i ett kalkylark". Begränsningarna kommer när du behöver komplex logik, hög volym eller ordentlig felhantering, då blir plattformen snabbt både dyr och trång.
Byrå eller specialistpartner är rätt när integrationen är affärskritisk, rör känslig data eller ska hålla i åratal, men ni saknar tid eller spetskompetens internt. Ni köper inte bara koden utan också arkitekturvalen, testningen och beredskapen när något går sönder.
En vanlig och fullt rimlig mix: plattform för de enkla interna flödena, specialistbyggd integration för det som pengarna flödar genom.
Varför integrationer går sönder
Integrationer är sköra på förutsägbara sätt, och det är här skillnaden mellan ett hastverk och ett hantverk syns.
- Versionsändringar. Leverantören uppdaterar sitt API, fält byter namn eller försvinner, och en integration som ingen bevakat slutar tyst att fungera. Bra integrationer bevakar versionsbesked och testas mot förändringar.
- Rate limits. De flesta API:er begränsar hur många anrop du får göra per minut. En integration som inte respekterar det blir blockerad mitt i en synkronisering, ofta vid sämsta tänkbara tillfälle.
- Felhantering. Nätverk går ner, system svarar långsamt, data kommer i oväntat format. En naiv integration kraschar eller, värre, tappar data i tysthet. En robust integration försöker igen med backoff, loggar vad som hände och larmar en människa när den inte kan lösa det själv.
Ett räkneexempel på varför det spelar roll: en ordersynk som tyst tappar en procent av alla ordrar låter harmlöst, tills du inser att det är bokföring som inte stämmer och kunder som inte fått leverans.
Vad en bra leverantör gör annorlunda
En bra integrationspartner skriver inte bara kod som fungerar på demodagen. Skillnaden sitter i det du inte ser: övervakning och larm så att fel upptäcks av systemet och inte av en arg kund, dokumentation så att nästa utvecklare förstår flödet, idempotens så att samma order aldrig bokförs två gånger, och en plan för vad som händer när tredjepartssystemet ändrar sig. Ställ frågan "hur märker vi när det går sönder?" till den ni pratar med, svaret säger mer än priset.
Vill du gå djupare i hur API:er blir en affärsstrategi snarare än bara teknik, läs vår artikel om API-strategi för SaaS-bolag. Och behöver du hjälp att bygga eller rädda en integration gör vi det dagligen, läs mer om API-integrationer hos Shapp.
