Queued with the change itself
An event is written in the same transaction as the change that caused it. If the change rolls back there is no event; if it commits the event cannot be dropped.
Het fundament eronderDeveloper platform
Uitgaande webhooks
Ondertekende events waarop een ander systeem zich kan abonneren. Er zijn er drie.
Growth-OS kan een ondertekend event naar een endpoint sturen als er iets verandert. Drie eventtypes zijn gebouwd: een wijziging in het organisatieprofiel, een abonnementswijziging en een afgeronde data-export. Geen enkel groeirecord stuurt er een, dus niets in ons dagelijks werk hangt hiervan af. Willen we later een ander intern hulpmiddel iets laten horen, dan staan de levering, de herhaalpogingen en de replay er al.
HMAC-SHA256signature on every event sent8delivery attempts before it stops30 daysof history that can be replayed
15 van 22 in Het fundament eronder
Productvoorbeeld
Bekijk het in werking
Dit is hetzelfde visuele component als in de ingelogde applicatie, met voorspelbare voorbeelddata.
Scenario
Voorbeeldscherm
Thema van voorbeeldoppervlak
Voorbeeldmodus
Delivery history
A signed delivery that succeeded next to a dead one that can still be replayed.
Inerte voorbeelddata · geen netwerktoegang
Voorbeeld gereed
Kernpunten
Waarom dit belangrijk is
Retries with patience
A receiver that is down gets up to 8 attempts with growing delays, then the delivery stops cleanly instead of looping.
A real answer to whether it sent
Every attempt records its status and a short response snippet, and an admin can replay a failed delivery for 30 days.
Het probleem dat dit oplost
Zonder een gedeelde basis bouwt elk team deze randgevallen opnieuw, en anders.
The event that never arrived
A receiver was down for a deploy and the event was sent inline with the request, so it simply died. No record, no retry, nothing to resend. Queueing the delivery with the change removes that whole category.
No way to prove it was us
Without a signature and a timestamp, a receiver cannot tell a real event from a forged one. Every delivery here is signed with the endpoint secret and carries the timestamp it was signed at.
Searching logs for a maybe
Someone asks whether an event went out and the only answer is a log search and a guess. With attempt history you see the failed status on attempt three and press replay.
Hoe het werkt
Het mechanisme van begin tot eind, zoals het in de repository is geïmplementeerd.
- 1
Events queue with the write
enqueueWebhookEvent runs inside the owning transaction, validates the payload against that event type and version, and inserts a delivery row per matching enabled endpoint.
- 2
A worker signs and sends
A background worker decrypts the endpoint secret, signs the body with the timestamp, and posts under a strict timeout.
- 3
Every attempt is recorded
Each try is claimed under a row lock before any network call, so it gets a durable attempt number. Only timeouts, conflicts, rate limits and server errors retry.
- 4
Dead deliveries wait for a person
After 8 attempts or 30 days a delivery is marked dead with its last error kept, and an admin can replay it through the same worker.
Technische garanties
Wat dit wel en niet belooft
Veiligheidsgrens
Alleen eventtypes die echt gebouwd zijn, worden genoemd; conceptdefinities blijven verborgen. De leveringsgeschiedenis toont statuscodes en korte fragmenten van het antwoord, nooit een ondertekeningsgeheim. De drie gebouwde events zijn vandaag allemaal platformevents, geen groeirecords.
Implementatiebewijs
De grens hierboven is geen claim maar code. Deze bestanden dragen het contract:
src/registries/webhook-events.tssrc/features/developer-platform/delivery.tssrc/features/developer-platform/jobs.tssrc/features/developer-platform/crypto.server.ts
Vragen
Veelgestelde vragen
Hiernaast gebruikt
Deze functies delen contracten en grenzen met deze pagina.
Waar Uitgaande webhooks op rust
De documentatie beschrijft dezelfde contracten die deze pagina demonstreert.