De 5 dolda riskerna med systemintegration

Häromdagen fick vi en brandkårsutryckning där en tredjepartstjänst hade ändrat sin API-endpoint som vi helt hade missat det.

Det var inte en enorm kris, utan någon timme felsökning och det var fixat. Men det satte igång diskussionen: hur hanterar vi egentligen våra tredjepartsintegrationer?

Några av riskerna med systemintegrationer är oklart ägarskap, breaking changes utan förvarningar, cascade failures, säkerhetsrisker och GDPR-komplexitet.

Nedan tittar vi på vad du behöver tänka på när du bygger integrationer som faktiskt håller.

1. Ägarskap och ansvar

Den första frågan är alltid: vem äger den här integrationen?

När något går fel klockan 03:00 på en lördag – vem ringer man? När en breaking change släpps – vem är då ansvarig för att uppdatera koden? Och när en kund frågar varför en synk inte funkar – vilket team ska då fixa det?

Det finns tre vanliga modeller för att organisera ägarskap. Den första är att produkt-teamet äger allt – både funktionen och själva integrationen. Det funkar bra i små bolag med få integrationer, men blir rörigt när flera team börjar använda samma API.

En annan modell är att ett dedikerat plattform-team äger alla tredjepartsintegrationer. Det skapar konsekvens och expertis, men kan bli en flaskhals när produkt-teamen vill gå snabbt.

Den tredje varianten är delat ägarskap: produkt-teamet äger business logic medan platform-teamet äger infrastruktur och övervakning. Kräver tydliga gränser och bra kommunikation, men ger ofta rätt balans.

Oavsett vilken modell du väljer behöver du definiera ansvar för varje integrering:

• Vem håller koll på leverantörens changelogs och deprecations?
• Vem äger övervakning och larm?
• Vem är first responder vid incidenter?
• Vem koordinerar uppdateringar och migrations?

Det är dock viktigt att tänka på att alla integrationer inte är lika kritiska. Så när du bedömer riskerna behöver du tänka på flera faktorer.

Hur mycket av din core functionality beror på detta API? Hur bra kommunicerar leverantören breaking changes? Hur ofta har de breaking changes eller outages? Och kan du byta till en annan leverantör, eller är du låst?

Dokumentera också detta någonstans. Det kan vara en wiki-tabell i Github, ett Notion-doc, eller bara en README i kodbasen. Poängen är att nästa person som ska hantera en incident vet vem som ansvarar.

2. Förvaltning och lifecycle management

Integrationer behöver alltid aktiv förvaltning. Det är verkligen inte något som du bara glömmer bort efter implementationen.

Detta beror på att tredjepartstjänster förändras konstant. Breaking changes släpps, nya versioner lanseras, gamla deprectas. Rate limits ändras, prismodeller uppdateras, säkerhetskrav skärps (OAuth flows, PKCE, etc.). Om du inte följer med hamnar du efter – och får reda på det först när något går sönder.

Det finns några rutiner som hjälper. Gå igenom alla integrationer kvartalsvis:

• Finns nya versioner eller deprecations?
• Har ert användningsmönster ändrats?
• Är kostnaden i förhållande till värdet fortfarande rätt?
• Behöver ni uppdatera felhanteringen?

Ett tips är också att prenumerera på RSS eller email från alla kritiska leverantörers changelogs. Om de inte har det räknas det som en risk i sig.

För API:er funkar inte Dependabot eller Renovate på samma sätt som för bibliotek – du behöver följa manuellt. Håll koll på nuvarande API-version ni använder, senaste tillgängliga version, deprecation-datum för er version (om känt), och estimerad effort för upgrade.

Ett verkligt exempel: Fortnox konsoliderade sina endpoints från apps.fortnox.se till api.fortnox.se och annonserade det på sin developer blog i januari. Om man inte följde deras changelog missade man det – och när cutover kunde det leda till att man fick generiska felmeddelanden utan tydlig kontext.

3. Resilience – hur du undviker cascade failures i API-integrationer

Din uptime är aldrig bättre än din svagaste länk.

Om din core functionality beror på ett tredjeparts-API som går ner, och du inte byggt för det - då finns det en risk att du också går ner.

Säg att din service har 99.9% uptime, men tredjepartstjänsten bara har 98%. Då finns det en risk att det kommer att påverka din uptime. Och med flera kritiska beroenden blir det värre.

Det finns tre huvudstrategier för att bygga resilience:

• Graceful degradation – Låt användaren göra något även när API:et är nere. Om Fortnox-API:et inte svarar när en användare ska skapa en faktura, spara fakturan lokalt som utkast och synka när API:et kommer upp igen. Användaren ser en varning men kan fortsätta jobba.

• Circuit breaker – När ett API är nere, sluta försöka anropa det. Om 50% av dina requests failar, "öppna circuiten" och returnera cached data eller felmeddelande direkt – utan att ens försöka. Efter 30 sekunder, testa igen. Annars överbelastar du ett redan kämpande API.

• Fallback till cached data – För read-operations (hämta kunder, produkter, etc), cacha aggressivt. Om API:et failar, returnera cached data med en flagga att det är "stale". Stale data är ofta bättre än ingen data. Funkar inte för write-operations, men för reads kan det rädda upplevelsen.

4. Övervakning och observability

Om du inte märker att något är fel kan du inte fixa det.

Många integrationer har övervakning som bara kollar "är HTTP status 200?". Det räcker inte.

Du behöver kolla mer än bara statuskoder. Validera att själva strukturen i svaret är densamma. Om ett API tyst ändrar sitt schema men returnerar 200 får du runtime errors långt ner i din kod.

Svarstider säger också mycket. Om ett API normalt svarar på 200ms men plötsligt tar 2000ms är något fel, även om det tekniskt funkar. Kanske håller de på att få problem.

Sätt inte bara larm på volym utan på nya typer av fel. Om du plötsligt får "deprecated endpoint"-errors är det viktigare än att du har 10% fler 500-errors.

Håll koll på hur nära rate limit du är. Om du normalt ligger på 30% men plötsligt är uppe i 80% riskerar du snart att bli begränsad.

Många API:er tar betalt per anrop – håll koll på förbrukningen mot budgeten så du inte får överraskningar.

När du bygger wrapper-funktioner runt API-anrop, logga svarstider för varje endpoint (för att se trender), validera svarsstrukturen (varning om den ändrats, inte error), logga full kontext vid fel (endpoint, status, body), och larma specifikt på nya typer av fel – inte bara volym.

En sak som sparar mycket tid: spara råa API-svar i 30 dagar för forensics. Om du kan gå tillbaka och se exakt vad API:et returnerade vid en incident slipper du mycket gissande.

5. Säkerhetsrisker med tredjepartsintegrationer

Tredjepartsintegrationer kan öka din attack surface enormt.

Det är svårt nog att hålla dina egna secrets säkra. När du integrerar mot 5-10 API:er har du lätt 10-20 keys/tokens att rotera, monitora och skydda. Och de flödar genom fler system blir det mycket svårare.

Vanliga problem: API keys hamnar i loggar när du debuggar och skriver ut hela request/response. Plötsligt finns de i Datadog, Sentry, CloudWatch.

Shared credentials är en annan risk. En API key för alla kunder – om den leakar måste du rotera för alla och alla går ner samtidigt.

Många keys skapas vid implementation och lever för alltid. Ingen rotation policy. När någon slutar har de fortfarande access.

GDPR-komplexitet blir också ett problem. Kundinformation flödar genom tredjepartstjänst till dina servrar och din databas. När en kund begär radering måste du spåra data i tre system.

Det finns några praktiska åtgärder som hjälper. Om möjligt, isolera credentials per tenant – ha separata API keys per kund. Om en kund läcker sin key påverkar det bara dem, inte alla andra kunder.

När du loggar requests/responses, maskera automatiskt fält som heter api_key, token, secret, password, authorization. Annars hamnar de överallt.

Rotera API keys var 90:e dag. Använd secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password).

Slutord

Tredjepartsintegrationer är inte "bara ett API-anrop" till. Det blir också ett långsiktigt beroende där du inte kontrollerar:

• När de släpper breaking changes
• Hur länge deras outages varar
• Om deras säkerhet är tillräcklig
• Om de höjer priserna eller ändrar villkor

Men med rätt governance, övervakning och resilience kan du dock minimera riskerna.

Glöm inte att definiera ägarskap. Bygg fallbacks. Övervaka på riktigt. Samt dokumentera vad som flödar vart.

Och nästa gång en tredjepartstjänst ändrar sitt API klockan 03:00 på en lördag – du vet vem som ansvarar, hur man debuggar, och vad fallback-planen är.