Carrier Webhooks Explained
What a carrier webhook is, how it differs from API polling and EDI, and how to verify and receive one — with a worked parcel-tracking example.
A carrier webhook is an HTTP callback that a carrier's system sends automatically to a URL you host the moment something happens to a shipment, label or tracking request, instead of you asking for that update. It is push, not pull, and it is a different mechanism from both API polling and EDI batch messages, even though all three move the same kind of logistics data.
If you run carrier connectivity for a European shipper, you've probably heard "webhook" used loosely for anything that arrives without a manual click. That looseness causes real confusion when your stack mixes EDIFACT messages from a road freight partner like DSV with a JSON webhook from a parcel carrier like GLS. This piece pins the term down properly, so you can use it correctly when scoping integration work or briefing a developer.
What a carrier webhook actually is
A webhook, also known as a web call-back, allows apps to share real-time information with other applications, and webhooks deliver data immediately as it happens, eliminating the need for frequent data polling. Applied to shipping, a shipment tracking webhook uses webhook technology to send shipment tracking data from carriers or tech providers to your system. The carrier (or an aggregator sitting in front of several carriers) holds a URL you gave them during setup. When a package gets scanned, delayed, or delivered, their system fires an HTTP POST to that URL with the event details. You don't request it. It just arrives.
The EasyPost engineering team put it plainly years ago: "Tracking webhooks essentially makes it so the carrier updates you without you having to ask." That's the entire concept in one sentence. Everything else in this post is detail around that core idea.
Webhook vs. API polling: the practical difference
Polling means your system repeatedly calls a carrier's API to ask "anything new?" on a timer, whether or not anything has actually changed. An API is used by a server to interact with another application, whereas a webhook is an automated call triggered by an event in another application. Functionally, both options allow parcel tracking worldwide, but webhooks deliver data immediately as it happens, eliminating the need for frequent data polling, while APIs require repeated calls to fetch data in real time.
The cost of polling shows up at scale in two ways: rate limits and infrastructure load. ShipStation's engineering blog is blunt about the first one: "If you've ever received a 429 error while shipping and tracking packages in high volumes, it's likely that you were making too many polling calls to the API." On the infrastructure side, the numbers get ugly fast. A platform tracking 10,000 active trips polled every 5 minutes generates over 2.8 million HTTP requests daily, creating heavy infrastructure costs and unnecessary server load. Scale that to a European retailer running parcel, LTL and FTL lanes across a dozen carriers and you're paying for a lot of "nothing changed" responses.
| Dimension | API polling | Webhook |
|---|---|---|
| Direction | Your system calls the carrier | Carrier calls your system |
| Latency | Bounded by poll interval (minutes to hours) | Near-immediate on event |
| Rate limit risk | High at volume, 429 errors common | Low, but endpoint must handle bursts |
| Infrastructure | Scheduler/cron jobs, always-on polling loop | Public HTTPS endpoint that accepts POST |
| Carrier support | Universal, every carrier with an API supports it | Not universal, varies by carrier |
Webhook vs. EDI: don't confuse the two
This is where European shippers trip up more than their US counterparts, because EDI is still the backbone for road freight here even as parcel moved to API years ago. An EDI message like IFTSTA is a structured document, exchanged on a schedule or in batches over AS2 or FTP, between two trading partners who negotiated the message format and connection in advance. A webhook is the opposite shape: one HTTP call, triggered by a single event, tied to one API account, with no pre-negotiated file structure beyond a JSON or XML schema the carrier publishes.
If you run DSV or DB Schenker on EDI for pallet freight and DHL or GLS on API with webhooks for parcel, you are not running "two flavors of the same thing." You're running two architecturally different integration patterns in parallel, and your monitoring, retry logic and failure alerting need to be built differently for each. EDI failures usually show up as a missing file on the FTP server at the expected batch window. Webhook failures show up as a missing event, often silently, because nothing tells you a POST didn't arrive unless you built that detection yourself.
How a carrier webhook works, step by step
The mechanics are consistent across carriers even when payload formats differ:
- You register a callback URL with the carrier during integration setup, usually alongside a shared secret used for signing.
- An internal event fires in the carrier's system, a scan, an exception, a proof of delivery.
- The carrier sends an HTTP POST to your URL with a JSON (sometimes XML) payload describing the event.
- Most carriers attach a signature header so you can verify the request actually came from them and wasn't tampered with in transit.
- Your endpoint verifies that signature, returns a fast 2xx response, and queues the payload for processing rather than handling it inline.
On the signature point: AfterShip, for example, includes an aftership-hmac-sha256 header with each webhook request, where the signature is a base64-encoded HMAC generated using the sha256 algorithm with the webhook request body and the webhook secret of your account. If your endpoint doesn't check that header, anyone who guesses or finds your URL can post fake delivery events into your system. That's not a theoretical risk, it's the first thing a security review will flag.
One more practical point: don't treat webhooks as 100% reliable. Webhooks mean a system can reflect a delivery or delay within seconds or minutes of the carrier reporting it, enabling rapid response, but in contrast, using a tracking API without webhooks requires constant polling to "ask" for updates, which is slower and inefficient. Carriers vary wildly in webhook reliability, so a light polling fallback every 30 to 60 minutes, just to catch anything missed, is standard practice rather than overengineering.
Worked example: FedEx and an aggregator approach
A concrete carrier-level example: FedEx's Tracking Account Number Webhook API allows you to register your FedEx account so that any shipment associated with that account, outbound, inbound, or third-party, will trigger a webhook event to your URL, meaning you get status updates like picked up, in transit, delayed, or delivered pushed automatically. You register once at account level, not per shipment, and every tracking number under that account starts generating events to your endpoint.
Now compare that to the aggregator pattern. AfterShip allows you to add tracking numbers with carrier info via their API, and then they send webhook callbacks to your URL, which means you integrate once against AfterShip rather than separately against FedEx, UPS, DHL, DPD and whoever else appears in your carrier mix that year. This is the same logic ShippyPro, Sendcloud, Shippo and ShipEngine use for parcel, and it's why TMS platforms split into two camps. Some, like Cargoson, nShift, Shiptify and FreightPOP, build and maintain the carrier-side webhook plumbing themselves, including for mixed parcel and LTL/FTL freight, so you're not rebuilding signature verification and retry logic for every new carrier relationship. Others expect you or a system integrator to wire up and monitor each carrier's webhook independently, which is exactly the maintenance burden that pushes large shippers toward a managed connectivity layer once their carrier count passes a certain threshold.
Common pitfalls when you build this yourself
Duplicate events, out-of-order delivery, and silent endpoint downtime are the three failure modes that catch teams off guard. Webhook delivery is typically at-least-once rather than exactly-once, so your handler needs idempotency checks, not just a listener. None of this is unique to carrier webhooks specifically, it applies to any production webhook integration, so we won't re-tread the full operational playbook here, check this blog's deeper posts on webhook authentication failures if you're debugging a live integration.
FAQ
Is a webhook the same as an API?
No. An API is something you call to request or send data. A webhook is the carrier calling you. Many carrier integrations use both: an API to create labels, a webhook to receive status updates.
Do all carriers support webhooks?
No. Many still require polling their tracking API, and plenty of European road freight carriers still run EDI IFTSTA messages over AS2 rather than offering any event-driven push option at all.
What happens if my webhook endpoint goes down?
Depends on the carrier's retry policy. Some retry with exponential backoff for a fixed window, others fire once and drop the event if you return an error or time out. This is exactly why a polling fallback matters.
Is a webhook secure by default?
No. A webhook is just an HTTP POST to a public URL. Without signature verification, typically an HMAC header, anyone who knows or guesses your endpoint URL can send fake events.
Can I use webhooks and EDI for the same carrier?
Yes, and it's common in hybrid European freight stacks where a single carrier group offers EDI for scheduled transport orders on one service line and a modern API with webhooks for parcel tracking on another.