Webhooks eller schemalagd synk?
Av CodexierPublicerad 5 min läsning
Varje integration mellan två system måste svara på en fråga: hur får system B veta att något ändrats i system A? Antingen skickar A ett meddelande i samma stund det händer, vilket är en webhook, eller så frågar B enligt ett schema, vilket är schemalagd synk eller polling. Båda fungerar. De fallerar olika, kostar olika och passar olika data. Den här guiden förklarar mekaniken med vanliga ord och ger en regel för att välja per flöde.
Vad webhooks och schemalagd synk är
| Aspekt | Webhook (push) | Schemalagd synk (pull) |
|---|---|---|
| Fördröjning | Sekunder | Schemats intervall: minuter till ett dygn |
| Vem tar initiativet | Källsystemet | Ert jobb |
| Om er sida ligger nere | Händelser går förlorade om inte källan försöker igen | Nästa körning plockar upp allt |
| Belastningsmönster | Ryckigt, följer aktiviteten | Förutsägbart, vid tider ni väljer |
| Kräver publik mottagning | Ja, med autentisering | Nej |
| Ordning och dubbletter | Måste hantera fel ordning och upprepade leveranser | Naturligt idempotent om rätt skriven |
Fart eller tillförlitlighet
Lockelsen med webhooks är omedelbarheten: en order i butiken dyker upp i CRM:et innan kunden stängt fliken. Priset är att varje händelse levereras en gång, till en mottagning som måste vara uppe, svara snabbt och klara att samma händelse kommer två gånger eller att två händelser kommer i fel ordning. En schemalagd synk ger upp omedelbarheten och vinner i gengäld en egenskap som betyder mer än de flesta väntar sig: den konvergerar. Vad som än gick fel i natt frågar kvällens körning efter allt sedan senaste lyckade kontrollpunkt och reparerar luckan.
- Fråga hur gammal datan får vara innan någon märker det eller tar skada. Är det ärliga svaret timmar räcker en synk.
- Fråga vad som händer om en händelse missas. Betyder en missad händelse att en kund aldrig faktureras behöver ni avstämning oavsett mekanism.
- Fråga vem som bevakar. En webhook som tyst slutar kräver övervakning på mottagarsidan. En synk som fallerar på natten kräver ett larm på morgonen.
Felhantering och omförsök
Integrationer bedöms efter hur de fallerar, inte hur de kör en bra dag. Båda angreppssätten kräver en plan för fel, men planerna ser olika ut.
Webhook: kvittera snabbt, bearbeta senare
Spara den inkommande händelsen och svara direkt, bearbeta sedan från kön. En långsam mottagning får timeout och källan kan sluta skicka.
Webhook: räkna med dubbletter
De flesta källor försöker igen vid fel, så samma händelse kan komma två gånger. Spara händelse-id och ignorera upprepningar. Gör varje uppdatering säker att köra två gånger.
Synk: kontrollpunkt med tid eller markör
Registrera senast lyckade tidsstämpel eller markör, och överlappa alltid lite vid nästa körning. Att missa ett fönster är värre än att bearbeta ett två gånger.
Båda: stäm av
Ett dagligt eller veckovis jobb som jämför antal och summor mellan systemen fångar det båda mekanismerna missat. Vår guide till Fortnox-integration visar varför det spelar roll för pengar.
Kostnader och begränsningar
Webhooks är billiga per händelse men kräver infrastruktur som alltid är igång: en publik mottagning, en kö, övervakning och någon som rättar när källan ändrar sitt format. Schemalagd synk förbrukar API-anrop i skurar, vilket slår i anropsgränserna hos system som Fortnox, HubSpot eller Shopify om intervallet är för kort eller datamängden för stor. Automationsplattformar fakturerar per operation, så en synk som kollar varje minut kan kosta långt mer än en webhook som bara avfyras när något händer.
- Kontrollera källsystemets anropsgränser och om det erbjuder ett ändrat-sedan-filter. Utan det måste polling hämta allt varje gång.
- Kontrollera om källan alls erbjuder webhooks och om den försöker igen. Vissa försöker i dagar, andra inte alls.
- Prissätt automationsplattformen per körning om ni använder en. Polling varje minut summerar snabbt.
- Budgetera utvecklartid för förändring: webhook-format och API-versioner ändras, och integrationen behöver en ägare.
Välj per dataflöde
Välj inte för hela projektet. Välj per flöde. Nytt lead från hemsidan till CRM:et: webhook, eftersom svarstid vinner affärer. Ordrar från butiken till bokföringen: nattlig synk med avstämning, eftersom korrekthet slår fart och redovisningskonsulten ändå jobbar på morgonen. Lagersaldon till en marknadsplats: webhook för försäljning plus en timvis synk som fångar avvikelser. Kundposter mellan två system: schemalagt, i en riktning, med ett definierat huvudsystem. Där ni behöver både fart och säkerhet kör ni webhooken för den snabba vägen och en schemalagd synk som skyddsnät. Det är den sortens design vi gör i vårt arbete med integrations- och automationsoptimering, ofta på integrationer som redan finns men fortsätter driva isär.
När ni inte behöver någotdera: utbyter två system en handfull poster i veckan är en manuell export och import, eller en inbyggd koppling med eget schema, billigare än att bygga och äga en integration. När flödet är verkligt, och särskilt om det flyttar pengar eller leads, är valet ovan värt en timmes eftertanke. Vill ni ha den timmen komprimerad till femton minuter med någon som byggt båda, boka ett kostnadsfritt samtal och ta med listan över system och vad som behöver flyttas mellan dem.
Vanliga frågor
Är webhooks säkrare än polling?
Ingendera är i sig säkrare. Webhooks kräver en publik mottagning som måste verifiera signatur eller hemlighet vid varje leverans och avvisa allt annat. Polling håller mottagningen privat men lagrar en API-nyckel som måste skyddas. Båda kräver samma omsorg om inloggningsuppgifter.
Hur ofta ska en schemalagd synk köras?
Så sällan datan tillåter. Nattligt är rätt för bokföring, timvis för lager och rapportering, med några minuters mellanrum för operativ data där en fördröjning syns för kunder. Kortare intervall kostar API-anrop och plattformsoperationer utan att tillföra värde om ingen agerar på datan snabbare.
Kan vi använda båda på samma data?
Ja, och för viktig data bör ni det. Webhooken ger fart, den schemalagda synken ger en periodisk fullständig kontroll som reparerar det webhooken missat. Båda måste göra uppdateringar på ett sätt som är säkert att upprepa.
Hanterar automationsverktyg som Zapier eller Make det här?
De stödjer båda utlösarna: omedelbara utlösare är webhooks, schemalagda utlösare är polling. De hanterar omförsök till viss del, men avstämning och dubbletthantering är fortfarande er design. Vid höga volymer blir priset per operation den avgörande faktorn.
Driver integrationen isär eller kommer datan sent?
Lista systemen och vad som måste flyttas mellan dem. På femton minuter säger vi vilka flöden som ska vara webhooks, vilka som ska schemaläggas och var ett avstämningsjobb skulle stoppa avvikelserna.
Boka ett kostnadsfritt 15-minuterssamtal