Webhooks vs Polling for Shipment Tracking: When to Use Each

Polling means your system periodically sends a tracking request for every active shipment and diffs the result against what it stored last time. Webhooks mean the tracking provider sends an HTTP POST to your endpoint whenever a shipment's status changes, and your system reacts to events instead of hunting for them.

Polling is pull: you control timing, retries, and load, and you pay for every question whether or not anything changed. Webhooks are push: you pay almost nothing for quiet shipments and learn about deliveries within seconds, but you inherit a public endpoint that must be secure, idempotent, and always available.

The math is brutal. A thousand active shipments polled every ten minutes is 144,000 lookups per day, and most of them return 'no change'. Shipments are quiet for long stretches: a cross-border parcel may scan twice in a week, yet naive polling asks about it hundreds of times between those scans.

Polling also creates latency floors. If you poll hourly, a package can sit on a doorstep for 59 minutes before your system knows it was delivered. Customers notice. Support tickets notice.

Webhooks invert the economics: you receive tracking.updated, tracking.delivered, and tracking.exception events only when something actually changed, and you receive them in seconds. Notification systems, order status pages, and SLA monitors all become event-driven and cheap.

The catch is that webhooks shift reliability work onto both sides. The provider must retry failed deliveries with backoff, sign payloads, and include event ids for idempotency. You must verify signatures, deduplicate events, and keep an endpoint healthy at 3 a.m. A webhook is a contract, not a feature.

Signatures first: every webhook should carry an HMAC signature over the raw body plus a timestamp, and your handler should reject anything older than a few minutes. Without that, anyone who discovers your endpoint can forge 'delivered' events into your system.

Then idempotency and ordering: providers retry, so you will receive duplicates; store processed event ids and make handlers safe to re-run. And never let a slow handler block the queue - acknowledge fast, process asynchronously.

In practice, mature systems use both. Webhooks drive the fast path: customer notifications, status page updates, exception alerts. A slow poll - every few hours for active shipments, never for delivered ones - acts as a safety net that catches missed webhooks and refreshes stale data.

The poll also solves the cold start: shipments created before webhooks were configured, or with providers that only support polling, still get tracked. Design the two paths to write the same normalized state, and the rest of your system never needs to know which one delivered the update.

For providers: signed payloads, exponential backoff retries for at least 24 hours, event ids, per-endpoint event selection, and a dashboard showing recent delivery attempts. For consumers: signature verification, idempotent handlers, fast acknowledgements, and alerting on your own failure rate.

If you are evaluating a tracking API, test the webhook story before the tracking story: send a test event, verify the signature header, watch a retry after you return a 500 on purpose. The quality of that loop predicts the quality of everything else.

Trace supports both models on the same normalized state: POST /v1/track for on-demand lookups with a 30-minute cache, and signed webhooks (Trace-Signature with t= and v1= HMAC SHA-256) for tracking.updated, tracking.delivered, and tracking.exception, with test delivery from the dashboard.

The recommended shape is the hybrid: let webhooks drive customer-facing updates, and keep a gentle poll for active shipments so a missed event never becomes a stale order status.