Once a parcel is with a carrier, your system has to find out when something happens to it. There are only two ways: ask repeatedly, or be told. Both are legitimate, and the choice has more consequences than it first appears.

Polling: asking repeatedly

Polling means your system calls the carrier's tracking endpoint on a schedule — every fifteen minutes, every hour — for shipments that are still in transit, and records anything that changed.

What is good about it

It works with every carrier that has a tracking API, needs no publicly reachable endpoint on your side, and fails in an obvious way: if polling stops, your data goes stale and monitoring notices. You are in control of the timing, so a burst of carrier activity cannot overwhelm you.

What is bad about it

Most polls return nothing new, so you spend API calls to learn that nothing happened. It scales badly — ten thousand active shipments polled hourly is a lot of wasted traffic, and carriers rate-limit. And your data is always up to one polling interval out of date, which shows up as a customer seeing "in transit" when the parcel was delivered forty minutes ago.

Webhooks: being told

A webhook means you give the carrier a URL, and they call it when a shipment's status changes. Your system receives the event and updates the record.

What is good about it

Near real-time updates, no wasted calls, and it scales with actual events rather than with the number of shipments you are watching. For customer-facing tracking and proactive notifications, this is a genuinely better experience.

What is bad about it

You need a publicly reachable, always-available endpoint. If your server is down for ten minutes, you may simply miss those events — some carriers retry, some do not, and the ones that do have their own retry policies. You are also now accepting inbound traffic from a third party, which has to be authenticated.

Webhooks also arrive out of order more often than people expect. A "delivered" event can land before the "out for delivery" event that preceded it, because they took different paths through a queue.

What a webhook endpoint actually needs

Accepting webhooks properly is more work than publishing a URL:

• Signature verification — confirm the call really came from the carrier, not from someone who guessed your URL
• Fast acknowledgement — accept the payload, queue it, return 200 immediately. Processing inline means slow processing looks like failure to the sender
• Deduplication — the same event will arrive twice. Handling it twice must be harmless
• Ordering by event time — use the carrier's timestamp, not arrival order, when building a timeline
• Unknown status handling — a status you have never seen must be flagged for review, not silently dropped

Why production systems use both

The honest answer is that webhooks are better and polling is safer, so mature systems take webhooks as the primary channel and keep a low-frequency poll as a safety net.

That reconciliation poll runs infrequently — perhaps a few times a day — over shipments that have had no events for longer than expected. It catches the cases webhooks silently miss: an outage on your side, a delivery failure on theirs, a shipment that quietly stopped producing events.

It costs very little and it is the difference between "our tracking is usually right" and "our tracking is right".

A practical decision guide

• Carrier offers webhooks and you can receive reliably → webhooks primary, reconciliation poll as backup
• Carrier has no webhooks → polling, with intervals tuned by shipment age
• Low volume, no public endpoint → polling is entirely reasonable; do not over-engineer
• Customer-facing tracking and notifications → webhooks are worth the effort, because latency is visible to customers

One refinement worth knowing: polling frequency does not have to be uniform. A shipment booked an hour ago and one that has been out for delivery since this morning deserve different intervals. Tiering by expected activity cuts call volume substantially without affecting the data you care about.

Where we come in

We build shipment tracking systems that ingest both, verify and queue webhook traffic, and reconcile against polling so gaps surface rather than accumulate. The related courier API integration work covers the carrier side of the same problem.