WEBHOOKS
Webhaken
Ontvang real-time gebeurtenissen van Superroute — orders, statuswijzigingen, tracking-updates. Met ondertekende payloads, automatische pogingen en ingebouwde debugger.
WEBHOOKS
Ontvang real-time gebeurtenissen van Superroute — orders, statuswijzigingen, tracking-updates. Met ondertekende payloads, automatische pogingen en ingebouwde debugger.
Een webhook is een HTTP POST die Superroute naar een door u geconfigureerde URL stuurt zodra er iets gebeurt — een order wordt aangemaakt, een levering voltooid, een tracking-event vastgelegd. U bouwt een ontvangstpunt, wij leveren het event daar af.
Events worden in de wachtrij geplaatst en asynchroon verzonden. Elk verzoek bevat een HMAC-SHA256 handtekening waarmee u de herkomst kunt verifiëren. Mislukte leveringen (geen 2xx of timeout) worden tot 5 keer opnieuw geprobeerd met exponentiële backoff.
U configureert een gedeeld geheim op de instellingenpagina. Elke uitgaande webhook wordt daarmee ondertekend. Uw ontvanger herberekent de handtekening en vergelijkt — bij match is de payload echt en onveranderd.
Er zijn acht uitgaande eventtypen beschikbaar. Elk heeft een eigen URL-veld op de instellingenpagina — abonneer u op elke gewenste subset.
Machineleesbare beschrijving van alle uitgaande gebeurtenissen, met payloadschema's, headers en herhaalschema's (AsyncAPI 3.0): asyncapi-webhooks.json
Vuurt bij aanmaak van een lokale bezorgorder (Delivery / Pickup / P2P) via elke route — webformulier, REST/GraphQL API, e-commerce platform sync, automatische regels, importregels, enz. Label-service en andere niet-bezorg ordertypes worden uitgesloten. Wordt in batch-flow overgeslagen wanneer voor dezelfde ontvanger ook order_create_async_postback_url is geconfigureerd. Configureer via order_create_webhook_url.
Payload-voorbeeldenVuurt bij elke statusovergang — opgehaald, onderweg, bezorgd, uitzondering, geannuleerd. Configureer via order_status_change_webhook_url.
Payload-voorbeeldenVuurt bij elk tracking-lifecycle event van een pakket (info ingediend, levering gestart, succesvol bezorgd, niet bezorgd, enz.). Configureer via tracking_event_webhook_url. Bezorg- en ophaalgebeurtenissen bevatten ook het afleverbewijs: proof_files en proof_files_detail (file_id, type, url, full_url, ondertekende download-URL). Foto’s die na de gebeurtenis worden geüpload, komen binnen als pod.files_updated. Elk bestand bevat ook de context van zijn gebeurtenis: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) en service_status (1 = success / 2 = failed); voor oude bestanden zonder vastgelegde gebeurtenis zijn ze null.
Payload-voorbeeldenVuurt eenmaal nadat een batch-import is verwerkt. Payload bevat de resultaten per regel. Configureer via order_create_async_postback_url.
Payload-voorbeeldenWordt geactiveerd wanneer een bezorgfoto of handtekening wordt toegevoegd, vervangen of verwijderd (action: added / updated / removed) — één levering per bestand, geen polling van bijlagen meer. Inschakelen via pod_files_webhook_url. Elk bestand bevat ook de context van zijn gebeurtenis: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) en service_status (1 = success / 2 = failed); voor oude bestanden zonder vastgelegde gebeurtenis zijn ze null. Wanneer een medewerker een foto of handtekening vervangt of een gearchiveerde versie als huidige instelt, wordt het bestand verzonden met action: updated en bevat het alleen de huidige afbeelding; gearchiveerde versies worden nooit verzonden.
Payload-voorbeeldenWordt geactiveerd wanneer een order permanent wordt verwijderd, zodat uw systeem de verwijdering kan spiegelen. Inschakelen via order_deleted_webhook_url.
Payload-voorbeeldenWordt geactiveerd wanneer een annuleringspoging wordt geweigerd (bijvoorbeeld omdat de order al onderweg is), zodat uw operationele processen mislukte annuleringen kunnen bewaken zonder de API te pollen. Inschakelen via order_cancel_failed_webhook_url.
Payload-voorbeeldenWordt verzonden wanneer een plaats op het routebord van houder wisselt of het bord van status verandert — het veld action zegt wat er gebeurde (claimed, standby, pooled, promoted, withdrawn, vetoed, replaced, assigned, awarded, lost, displaced, settled, board_opened, board_closed, board_cancelled). Alleen op bedrijfsniveau. Opt-in via route_board_webhook_url.
Payload-voorbeeldenEen apart webhookkanaal voor externe bezorgaanbieders die met slimme lockers integreren. Gebeurtenissen worden bezorgd op het endpoint dat voor uw aanbiederaccount is geconfigureerd; elk endpoint kan zich op elke subset van gebeurtenistypen abonneren.
Deuren Geopend — Wordt geactiveerd zodra de vakdeuren opengaan voor een bezorgpoging — of de koerier nu de toegangscode op het scherm van de kluis invoerde of de remote-open-API gebruikte — inclusief heropeningen na hertoewijzing. Het opening-blok toont elk geopend vak met grid_id, hardware-deurnummer compartment_number en pickup_locker_number (volgnummer voor weergave, per kolom van boven naar beneden geteld en daarna van links naar rechts). Elk vak bevat ook pickup_locker_code — het label "{shelf_code}-{pickup_locker_number}" waar de ontvanger naartoe wordt gestuurd; null als het vak geen afhaalnummer heeft. De payload bevat ook pickup_code — de afhaalcode van de ontvanger, toegewezen op het moment dat de deuren opengaan; die blijft dezelfde code nadat de koerier het deponeren bevestigt en kan pas na die bevestiging voor afhalen worden gebruikt.
Payload-voorbeeldenBezorgd in kluis — Wordt geactiveerd wanneer een aflevering is bevestigd en de pakketten in de locker liggen. De payload bevat de ophaalcode van de ontvanger. Elk vak bevat ook pickup_locker_code — het label "{shelf_code}-{pickup_locker_number}" waar de ontvanger naartoe wordt gestuurd; null als het vak geen afhaalnummer heeft. Voor deuren die via de API voor openen op afstand zijn geopend, wikkelt het platform de aflevering zelf af zodra de locker meldt dat alle geopende deuren weer dicht zijn; het event wordt dan zonder confirm-aanroep verstuurd. confirmed_by geeft de afwikkelingsroute aan: courier_terminal, partner_api, door_close, timeout_door_closed of console.
Payload-voorbeeldenOpgehaald — Wordt geactiveerd wanneer de ontvanger de gedeponeerde pakketten heeft opgehaald.
Payload-voorbeeldenBezorging mislukt — Wordt geactiveerd wanneer een bezorging mislukt; foutcodes per pakket zijn inbegrepen.
Payload-voorbeeldenVerlopen — Wordt geactiveerd wanneer een ongebruikte bezorgcode of een niet-opgehaalde deponering de vervaltijd overschrijdt.
Payload-voorbeeldenGeannuleerd — Wordt geactiveerd wanneer een bezorging vóór voltooiing wordt geannuleerd.
Payload-voorbeeldenCorrectie-heropening — Wordt geactiveerd wanneer de gebruikte vakken binnen het correctievenster opnieuw worden geopend om een verkeerde plaatsing te herstellen — via het lockerscherm of via de API. Het correction-blok vermeldt de heropende vakken. Elk vak bevat ook pickup_locker_code — het label "{shelf_code}-{pickup_locker_number}" waar de ontvanger naartoe wordt gestuurd; null als het vak geen afhaalnummer heeft.
Payload-voorbeeldenOphaalcode gewijzigd — Wordt geactiveerd wanneer de partner de bezorgcode of afhaalcode van een bezorging vernieuwt. Het rotation-blok vermeldt welke code is vervangen, wanneer, en of de ontvangermelding opnieuw is verzonden — de nieuwe code zelf reist nooit mee in een webhook; die wordt alleen onthuld in het directe antwoord van de vernieuwings-API.
Payload-voorbeeldenVervoerderspakket gedistribueerd — Wordt afgevuurd wanneer een vooraangekondigd vervoerderspakket dat bij een magazijn is ontvangen op een distributieorder naar de door de vervoerder genoemde locatie wordt gezet. Het data-blok bevat het pakketnummer, de vervoerdersreferentie en het lidnummer, de distributieorder (order_id, order_ref, status) en de locaties van vertrek en bestemming. Alleen vastgelegd voor vervoerders met een leveranciersaccount.
Payload-voorbeeldenVervoerderspakket geladen — Wordt afgevuurd wanneer het pakket bij het vertrekmagazijn op de vrachtwagen wordt gescand; distribution.status is in_transit en loaded_at is gezet.
Payload-voorbeeldenVervoerderspakket bezorgd op locatie — Wordt afgevuurd wanneer de chauffeur de distributieorder op de locatie overdraagt; distribution.status is delivered en delivered_at is gezet. Opslag is een latere, aparte gebeurtenis.
Payload-voorbeeldenVervoerderspakket opgeslagen op locatie — Wordt afgevuurd wanneer het pakket op de locatie wordt opgeslagen, in een kluisvak of op een stelling; location bevat grid_id, grid_code en shelf_code. De ophaalmelding aan de ontvanger gaat op dat moment uit.
Payload-voorbeeldenVervoerderspakket uit distributie verwijderd — Wordt afgevuurd wanneer het pakket vóór vertrek van een distributieorder wordt gehaald of de order wordt geannuleerd; distribution.reason is removed of cancelled. Het pakket staat weer op de distributielijst van het magazijn.
Payload-voorbeeldenHandtekening & Verificatie: Aanbiederlocker-webhooks gebruiken een eigen ondertekeningsschema: X-Webhook-Signature is base64(HMAC-SHA256(geheim, tijdstempel + "\n" + bezorgings-id + "\n" + ruwe body)), waarbij de tijdstempel en bezorgings-id uit de headers X-Webhook-Timestamp en X-Webhook-Delivery-Id komen. Controleer ook X-Webhook-Content-Digest (SHA-256 van de body) en weiger verouderde tijdstempels. X-Webhook-Id blijft stabiel over nieuwe pogingen — gebruik deze voor idempotentie.
Hoe configureren: Endpoints beheert u onder Externe bezorging → Aanbiederlocker → Instellingen, één endpoint per aanbieder, met een selecteerbare gebeurtenislijst. Mislukte bezorgingen worden met exponentiële backoff tot 7 keer opnieuw geprobeerd voordat ze in de dead letter belanden; dead-lettergebeurtenissen kunnen handmatig opnieuw worden verzonden vanaf de gebeurtenissenpagina.
Sandbox-gebeurtenissen (mock-kluizen): Bezorgingen op mock-kluizen genereren dezelfde webhook-gebeurtenissen als productie, ondertekend met hetzelfde secret, zodat u met realistisch verkeer kunt ontwikkelen. Sandbox-gebeurtenissen zijn op drie manieren gemarkeerd: de payload bevat "livemode": false, de event_id begint met PLE-MOCK- en het verzoek draagt de header X-Webhook-Test: 1. Als op het endpoint een sandbox-URL is geconfigureerd, gaan sandbox-gebeurtenissen daarheen in plaats van naar de productie-URL; anders vallen ze terug op de productie-URL, nog steeds gemarkeerd. De schakelaar "Sandbox-gebeurtenissen bezorgen" stopt de sandbox-bezorging volledig.
Pakketbezorging-webhooks die naar externe bezorgaanbieders (koeriers) worden gepusht. Ze dekken de levenscyclus van bezorgtoewijzingen, zodat een koerier niet meer hoeft te pollen naar nieuwe opdrachten. Deze categorie staat los van de onderstaande slimme locker-gebeurtenissen: elke aanbieder configureert per categorie een eigen endpoint, ondertekeningsgeheim en gebeurtenisabonnement — in zijn eigen aanbiedersportaal of via de platformbeheerder.
Toewijzing aangemaakt — Wordt geactiveerd wanneer een order aan de aanbieder wordt toegewezen — via een automatische regel of handmatig. De payload bevat het toewijzingsnummer, de order-ID's en de trackingnummers van de pakketten.
Payload-voorbeeldenPakketten overgedragen — Wordt geactiveerd wanneer het magazijn alle pakketten van de toewijzing fysiek aan de aanbieder heeft overgedragen.
Payload-voorbeeldenToewijzing geannuleerd — Wordt geactiveerd wanneer het platform een toewijzing bij de aanbieder intrekt. Het veld reason maakt onderscheid tussen cancelled (de toewijzing is bij de vervoerder geannuleerd), fallback_to_self_delivery (het platform heeft de order teruggenomen voor eigen bezorging) en reassigned (de order is naar een andere aanbieder verplaatst).
Payload-voorbeeldenGedeeltelijk bezorgd — Wordt geactiveerd wanneer een deel van een zending is bezorgd terwijl andere pakketten nog onderweg zijn. De array packages bevat het resultaat per pakket en legs somt de bij de vervoerder geboekte externe orders op — één per pakket als de vervoerder geen multi-collo zendingen accepteert.
Payload-voorbeeldenHandtekening & Verificatie: Webhooks voor externe bezorging gebruiken hetzelfde ondertekeningsschema als aanbiederlocker-webhooks: X-Webhook-Signature is base64(HMAC-SHA256(secret, timestamp + "\n" + delivery id + "\n" + raw body)), waarbij de timestamp en delivery id uit de headers X-Webhook-Timestamp en X-Webhook-Delivery-Id komen. Controleer ook X-Webhook-Content-Digest (SHA-256 van de body) en weiger verouderde tijdstempels. X-Webhook-Id blijft stabiel over nieuwe pogingen — gebruik deze voor idempotentie.
Hoe configureren: Aanbieders configureren dit endpoint zelf in het aanbiedersportaal (Webhook-instellingen), of de platformbeheerder doet dit onder Externe bezorging → Aanbieders → Webhooks. Eén endpoint per aanbieder met een selecteerbare gebeurtenislijst. Het ondertekeningsgeheim kan automatisch worden gegenereerd of op een eigen waarde worden ingesteld, en is te bekijken op de instellingenpagina. Mislukte bezorgingen worden met exponentiële backoff tot 7 keer opnieuw geprobeerd voordat ze in de dead letter belanden; dead-lettergebeurtenissen kunnen handmatig opnieuw worden verzonden. Vanaf de instellingenpagina kan op elk moment een ondertekende test- (mock-)gebeurtenis worden verzonden — testverzoeken dragen de header X-Webhook-Test: 1 en bevatten "test": true in de payload-data.
Ondertekende pushes over overdrachten via het Open Order Handoff Protocol: levenscyclusveranderingen (geaccepteerd, geweigerd, verlopen, geannuleerd), antwoorden op wijzigingen, trackingevenementen en nieuwe afrekeningsregels. Geabonneerd per OHP-token via POST /api/v1/ohp/subscriptions; het endpoint moet eerst een challenge terugkaatsen voordat het abonnement bestaat. Elke payload is de OHP-envelop; message_id blijft bij elke nieuwe poging gelijk — dedupliceer daarop. Pull blijft de bron van waarheid.
Handtekening & Verificatie: X-Ohp-Signature: v1= + hex HMAC-SHA256 van "{timestamp}.{raw body}" met het abonnementsgeheim. X-Ohp-Timestamp verandert per poging; X-Ohp-Delivery is gelijk aan message_id. CloudEvents en Standard Webhooks zijn per abonnement beschikbaar.
Hoe configureren: Beheerd met het OHP-token: POST /api/v1/ohp/subscriptions (url, secret, events, format, signature), GET om te tonen, DELETE om in te trekken. De machineleesbare catalogus toont elk evenement onder de afzender ohp.
Fijnmazige, opt-in gebeurtenissen naast de klassieke order.status_change-webhook (die ongewijzigd blijft): wie is toegewezen, of de chauffeur heeft geaccepteerd, wanneer het pakket is opgehaald, onderweg is, bezorgd is of mislukt is, plus wijzigingen in de chauffeursdienst en gedoseerde chauffeursposities. Er wordt niets verzonden totdat u de onderstaande URL's configureert.
Er is een chauffeur aan de order toegewezen (handmatig, via ritplanning of via automatische toewijzing). data.source = auto_assign wanneer de orchestrator dit deed.
Payload-voorbeeldenDe order is zijn chauffeur kwijtgeraakt (overdracht, intrekking, weigering, time-out). data.previous_driver_id geeft aan wie hem had.
Payload-voorbeeldenDe chauffeur heeft een automatisch toegewezen order in de app geaccepteerd (chauffeursdienst met verplichte acceptatie).
Payload-voorbeeldenDe chauffeur heeft een toegewezen order geweigerd; data.reason bevat de optionele reden in vrije tekst.
Payload-voorbeeldenDe chauffeur is met ophalen begonnen (status Ophalen gestart / Onderweg voor ophalen).
Payload-voorbeeldenHet pakket is opgehaald (status Al opgehaald).
Payload-voorbeeldenHet pakket is onderweg naar de ontvanger (status Bezorging gestart / Onderweg voor bezorging).
Payload-voorbeeldenDe bezorging is geslaagd (status Succesvol).
Payload-voorbeeldenDe bezorgpoging is mislukt (Later opnieuw bezorgen, Opnieuw plannen, Afgewezen door ontvanger).
Payload-voorbeeldenDe order is geannuleerd.
Payload-voorbeeldenEen medewerker (of een chauffeur, indien toegestaan) heeft de order als gereed voor ophalen gemarkeerd (Dispatchopties → gereed voor ophalen).
Payload-voorbeeldenEen chauffeur is in de app in of uit dienst gegaan (optie chauffeursdienst).
Payload-voorbeeldenEen chauffeurspositie uit de app of tracker, per chauffeur gedoseerd via driver_location_min_interval_sec (standaard 60 s). Wordt alleen naar driver_location_webhook_url verzonden.
Payload-voorbeeldenHoe configureren: Instellingen → Webhooks (of GET/PUT /api/v1/webhook-settings, GraphQL webhookSettingsUpdate): order_lifecycle_webhook_url ontvangt elke order.*-gebeurtenis en driver.on_duty_changed; order_lifecycle_events beperkt dat tot een door komma's gescheiden lijst; driver_location_webhook_url en driver_location_min_interval_sec regelen driver.location_update. Meerdere URL's kunnen door komma's worden gescheiden. Verzendingen verschijnen in het webhook-bezorglogboek met reference_type order / driver.
Handtekening & Verificatie: Ondertekend precies zoals elke andere uitgaande webhook van uw account: legacy Signature-header plus X-Webhook-Id / X-Webhook-Timestamp / X-Webhook-Signature-V2 met uw webhook_sign_secret. Nieuwe pogingen hergebruiken dezelfde event_id – dedupliceer daarop.
Optionele gebeurtenissen voor pakketten die door uw slimme kluizen, kiosken en smart drops worden verwerkt: een pakket opgeslagen in een automaat, opgehaald, door medewerkers eruit gehaald of over de ophaaltermijn heen, en problemen die daarover zijn geopend of opgelost. Uitsluitend aanvullend — geen bestaande webhook verandert en er wordt niets verzonden totdat u device_order_webhook_url instelt.
Een pakket is in de automaat geplaatst en wacht op de volgende persoon (ontvanger, koerier of beheerder, zie data.device_order.next_actor). due_at is de uiterste ophaaldatum.
Payload-voorbeeldenHet pakket is eruit gehaald door de persoon op wie het wachtte — de ontvanger, de koerier of medewerkers die een smart drop legen.
Payload-voorbeeldenMedewerkers hebben het pakket uit de automaat gehaald. removal_reason geeft de reden: overdue_return, handover, relay, anomaly of recovery.
Payload-voorbeeldenHet pakket is over zijn due_at heen zonder te zijn opgehaald. Het ligt nog in de automaat en de code werkt nog; overdue_at wordt ingesteld en next_actor wordt operator.
Payload-voorbeeldenEr is een probleem geopend voor de verwerking (bijvoorbeeld door_left_open, deposit_unverified, item_missing, overdue). data.exception bevat id, type, severity en status.
Payload-voorbeeldenIemand heeft een probleem van de verwerking gesloten. data.exception.status is resolved of dismissed en resolution_action geeft aan wat er is gedaan.
Payload-voorbeeldenPayload-voorbeelden: data.device_order: id, kind, status, next_actor, device_type, device_id, device_name, grid_code, reference_number, order_id, external_order_id, due_at, overdue_at, stored_at, ended_at, removal_reason (tijden in ISO 8601, null zolang niet bereikt). Probleemgebeurtenissen voegen data.exception toe: id, type, severity, status, resolution_action. De ophaalcode wordt nooit meegestuurd. event_id is DOE-<id van de registergebeurtenis> en blijft gelijk bij nieuwe pogingen.
Hoe configureren: Instellingen → Webhooks (of GET/PUT /api/v1/webhook-settings): device_order_webhook_url ontvangt elke device_order.*-gebeurtenis; device_order_events beperkt dit tot een door komma's gescheiden lijst. Meerdere URL's kunnen door komma's worden gescheiden. Afleveringen verschijnen in het webhook-afleverlogboek met reference_type device_order.
Handtekening & Verificatie: Ondertekend precies zoals elke andere uitgaande webhook van uw account: legacy Signature-header plus X-Webhook-Id / X-Webhook-Timestamp / X-Webhook-Signature-V2 met uw webhook_sign_secret. Nieuwe pogingen hergebruiken dezelfde event_id – dedupliceer daarop.
Pakketten die een partnervervoerder onder zijn eigen account in uw kluizen aflevert, worden niet via dit kanaal verzonden; de partner ontvangt ze via zijn eigen leverancierskluis-webhooks.
U kunt webhooks op twee niveaus configureren: op bedrijfsniveau (dekt alles) of per klant (overschrijft voor dat specifieke B2B-subaccount).
Log in en ga naar Instellingen → API & Webhooks. Klant-overschrijvingen staan op de klantdetailpagina.
Kies een string van minimaal 16 tekens, idealiter 32+ willekeurige bytes. Uw ontvanger gebruikt dit geheim om handtekeningen te verifiëren.
Vul alleen URLs in voor events die u nodig heeft. Laat de rest leeg.
webhook_sign_geheimU configureert een gedeeld geheim op de instellingenpagina. Elke uitgaande webhook wordt daarmee ondertekend. Uw ontvanger herberekent de handtekening en vergelijkt — bij match is de payload echt en onveranderd.order_create_webhook_urlVuurt bij aanmaak van een lokale bezorgorder (Delivery / Pickup / P2P) via elke route — webformulier, REST/GraphQL API, e-commerce platform sync, automatische regels, importregels, enz. Label-service en andere niet-bezorg ordertypes worden uitgesloten. Wordt in batch-flow overgeslagen wanneer voor dezelfde ontvanger ook order_create_async_postback_url is geconfigureerd. Configureer via order_create_webhook_url.order_status_change_webhook_urlVuurt bij elke statusovergang — opgehaald, onderweg, bezorgd, uitzondering, geannuleerd. Configureer via order_status_change_webhook_url.tracking_event_webhook_urlVuurt bij elk tracking-lifecycle event van een pakket (info ingediend, levering gestart, succesvol bezorgd, niet bezorgd, enz.). Configureer via tracking_event_webhook_url. Bezorg- en ophaalgebeurtenissen bevatten ook het afleverbewijs: proof_files en proof_files_detail (file_id, type, url, full_url, ondertekende download-URL). Foto’s die na de gebeurtenis worden geüpload, komen binnen als pod.files_updated. Elk bestand bevat ook de context van zijn gebeurtenis: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) en service_status (1 = success / 2 = failed); voor oude bestanden zonder vastgelegde gebeurtenis zijn ze null.order_create_async_postback_urlVuurt eenmaal nadat een batch-import is verwerkt. Payload bevat de resultaten per regel. Configureer via order_create_async_postback_url.pod_files_webhook_urlWordt geactiveerd wanneer een bezorgfoto of handtekening wordt toegevoegd, vervangen of verwijderd (action: added / updated / removed) — één levering per bestand, geen polling van bijlagen meer. Inschakelen via pod_files_webhook_url. Elk bestand bevat ook de context van zijn gebeurtenis: tracking_event_id, tracking_event_status_id, tracking_event_key, service_type (1 = delivery / 2 = pickup) en service_status (1 = success / 2 = failed); voor oude bestanden zonder vastgelegde gebeurtenis zijn ze null. Wanneer een medewerker een foto of handtekening vervangt of een gearchiveerde versie als huidige instelt, wordt het bestand verzonden met action: updated en bevat het alleen de huidige afbeelding; gearchiveerde versies worden nooit verzonden.order_deleted_webhook_urlWordt geactiveerd wanneer een order permanent wordt verwijderd, zodat uw systeem de verwijdering kan spiegelen. Inschakelen via order_deleted_webhook_url.order_cancel_failed_webhook_urlWordt geactiveerd wanneer een annuleringspoging wordt geweigerd (bijvoorbeeld omdat de order al onderweg is), zodat uw operationele processen mislukte annuleringen kunnen bewaken zonder de API te pollen. Inschakelen via order_cancel_failed_webhook_url.route_board_webhook_urlWordt verzonden wanneer een plaats op het routebord van houder wisselt of het bord van status verandert — het veld action zegt wat er gebeurde (claimed, standby, pooled, promoted, withdrawn, vetoed, replaced, assigned, awarded, lost, displaced, settled, board_opened, board_closed, board_cancelled). Alleen op bedrijfsniveau. Opt-in via route_board_webhook_url.device_order_webhook_urlOptionele gebeurtenissen voor pakketten die door uw slimme kluizen, kiosken en smart drops worden verwerkt: een pakket opgeslagen in een automaat, opgehaald, door medewerkers eruit gehaald of over de ophaaltermijn heen, en problemen die daarover zijn geopend of opgelost. Uitsluitend aanvullend — geen bestaande webhook verandert en er wordt niets verzonden totdat u device_order_webhook_url instelt.Alles wat nieuw is in de API en webhooks — idempotent annuleren, reconciliatie-feeds, v2-handtekeningen, nieuwe events — met kant-en-klare voorbeelden. Alles volledig backwards compatible.
Elke uitgaande webhook bevat een hex-gecodeerde HMAC-SHA256 handtekening in de header. Uw ontvanger moet de handtekening herberekenen over de ruwe body met het gedeelde geheim en het verzoek afwijzen als het niet overeenkomt.
Elke webhook-URL kan gebeurtenissen ontvangen in het native formaat of als CloudEvents, en kan daarnaast Standard Webhooks-handtekeningheaders krijgen. Dit stelt u per URL in bij de webhookinstellingen. Een URL zonder instelling ontvangt gebeurtenissen precies zoals voorheen.
native — De JSON-body en headers die op deze pagina worden beschreven.ce_binary — Dezelfde body; de CloudEvents-attributen worden als ce-*-headers verzonden.ce_structured — De body is een CloudEvent (Content-Type: application/cloudevents+json) met de native body in data. Hij is bij elke nieuwe poging gelijk en de native handtekeningen dekken hem.ce-id en webhook-id bevatten de eigen event_id van de gebeurtenis als de body die heeft, anders X-Webhook-Event-Id. X-Webhook-Event-Id zelf verandert niet. ce-source en ce-srbusiness noemen het bedrijf, ook bij leveringen aan zijn klanten.
Webhooks voor leveringen in partnerkluisjes en externe bezorging bieden dezelfde keuze per endpoint, op de pagina met webhookinstellingen van de aanbieder. Callbacks van laadplannen en Open Platform krijgen die per verzoek: callback_format en callback_signature, of callback.format en callback.signature. Daarbij zijn ce-id en webhook-id de eigen id van de gebeurtenis (X-Webhook-Id, X-Webhook-Event-Id of X-Open-Delivery), noemt ce-source het verzendende bedrijf, en bevat webhook-signature gedurende 24 uur na een rotatie van een aanbiedersleutel één handtekening per sleutel.
Datasetwebhooks bieden dezelfde keuze per webhook, in het formulier van de webhook en in de API (event_format en standard_signature). Standard Webhooks gebruikt de geheime sleutel van de webhook en heeft er dus een nodig. URL's van datasetwebhooks moeten openbare HTTPS-adressen zijn.
Met Standard Webhooks bevat elke levering ook webhook-id, webhook-timestamp en webhook-signature. Ze worden bij elke nieuwe poging opnieuw ondertekend, zodat ook een nieuwe poging binnen een tolerantie van 5 minuten valt. De sleutel is uw webhook-ondertekeningssleutel in whsec_-vorm, getoond op de instellingenpagina. De native headers worden nog steeds verzonden.
Elke afzender ondertekent anders. De headernaam X-Webhook-Signature wordt door drie afzenders met drie verschillende methoden gebruikt; controleer met de methode van de afzender die u aanriep.
| Afzender | Headers | Handtekening |
|---|---|---|
| Tenant-webhooks (deze pagina) | Content-Type, Signature, X-Webhook-Event-Id, X-Webhook-Timestamp, X-Webhook-Signature-V2 |
Signature = hex(HMAC-SHA256(body))
X-Webhook-Signature-V2 = hex(HMAC-SHA256(timestamp + "." + body)) |
| Leveringen in partnerkluisjes | Content-Type, X-Webhook-Id, X-Webhook-Delivery-Id, X-Webhook-Timestamp, X-Webhook-Key-Id, X-Webhook-Content-Digest, X-Webhook-Signature, X-Webhook-Test |
X-Webhook-Signature = "v1=" + base64(HMAC-SHA256(timestamp + "\n" + delivery_id + "\n" + body)) |
| Toewijzingen aan externe bezorging | Content-Type, X-Webhook-Id, X-Webhook-Delivery-Id, X-Webhook-Timestamp, X-Webhook-Key-Id, X-Webhook-Content-Digest, X-Webhook-Signature |
X-Webhook-Signature = "v1=" + base64(HMAC-SHA256(timestamp + "\n" + delivery_id + "\n" + body)) |
| Callbacks van laadplannen | Content-Type, X-Webhook-Event-Id, X-Webhook-Event-Type, X-Webhook-Timestamp, X-Webhook-Signature |
X-Webhook-Signature = "v1=" + hex(HMAC-SHA256(timestamp + "." + body)) |
| Callbacks van Open Platform-taken | Content-Type, X-Open-Event, X-Open-Delivery, X-Open-Job, X-Open-Timestamp, X-Open-Signature |
X-Open-Signature = "v1=" + hex(HMAC-SHA256(timestamp + "." + body)) |
| OHP push | Content-Type, X-Ohp-Event, X-Ohp-Delivery, X-Ohp-Timestamp, X-Ohp-Signature |
|
| Datasetwebhooks | Content-Type, X-Webhook-Event, X-Webhook-Timestamp, X-Webhook-Signature |
X-Webhook-Signature = hex(HMAC-SHA256(body)) |
| Tenant-webhooks met Standard Webhooks | webhook-id, webhook-timestamp, webhook-signature |
webhook-signature = "v1," + base64(HMAC-SHA256(webhook-id + "." + webhook-timestamp + "." + body)) |
Uw dienstverlener kan zijn prijzen voor een klantaccount verbergen, per ordertype (Lokale Levering, Labeldienst, Verzendservice, LTL-service, Opslagdiensten, Verhuisservices, apparaatorders). Als dat voor u geldt, bevatten leveringen aan uw endpoint geen prijsvelden: shipping_price, price_details, currency, belasting, toeslagbedragen, tariefprijzen en dergelijke worden weggelaten in plaats van als nul verzonden. Tarieflijsten behouden rate_id en servicenamen zodat u nog steeds een service kunt kiezen.
Uw endpoint moet snel met 2xx antwoorden. Anders, bij timeout of onbereikbaarheid, wordt de levering opnieuw geprobeerd.
Plak een ontvangen payload, de Signature-headerwaarde en uw geheim — de tool herberekent de handtekening in uw browser (niets verlaat deze pagina) en meldt of ze overeenkomen.
Vuur een echte, correct ondertekende webhook af vanaf onze server naar een door u opgegeven URL. Gebruik dit om bereikbaarheid, payload-parsing en handtekening-verificatie te testen.
Bekijk de meest recente webhook-leveringspogingen op uw account — zowel productie-events als tests vanaf deze pagina. Plak uw Bearer token om te laden.
Leveringsrecords worden 90 dagen bewaard.
Een handmatige herlevering krijgt een nieuwe X-Webhook-Event-Id. Een event_id die de gebeurtenis zelf draagt (pod.files_updated, order.deleted, levenscyclus- en apparaatordergebeurtenissen) behoudt de oorspronkelijke waarde.
| Tijd | Evenement | URL | Status | HTTP | Poging | Tijd (ms) | Testen? | Acties |
|---|---|---|---|---|---|---|---|---|
| Nog geen webhook-leveringen gevonden. | ||||||||