When you add shipment visibility to an application, you need a way to learn when tracking status changes. Two common patterns are carrier webhooks and polling: receiving a notification when an event occurs, or asking for the latest status on a schedule.
Webhooks are useful when the carrier or tracking provider offers dependable event delivery and your application can receive and process those events. But carrier webhook support is not uniform. Some carriers or services may not offer a webhook interface that fits your integration. In that case, polling gives you a practical way to check for updates.
For a multi-carrier workflow with uneven webhook support, I prefer controlled polling. It works through a consistent request-and-response integration and lets the application choose how often to check each shipment. The tradeoff is that polling uses requests and may not see a change until the next check.
How the two approaches differ
| Consideration | Webhook | Scheduled polling |
|---|---|---|
| How an update arrives | The provider sends an event to an endpoint you operate. | Your application requests the latest available status. |
| Carrier support | Depends on the carrier, service, and provider integration. | Works wherever the tracking API supports status requests. |
| Application work | Requires a reachable receiver, signature checks, retries, and duplicate-event handling. | Requires a scheduler, request budgeting, and comparison with the last saved result. |
| Update timing | Can arrive soon after an event, subject to provider delivery. | Changes are discovered at the next scheduled check. |
| Usage pattern | Event-driven; your system must be ready to accept callbacks. | Predictable request volume that you can tune by shipment stage. |
Neither approach guarantees that a carrier scan exists or that it will be available immediately. A webhook can be delayed or retried; a poll can return the same cached or unchanged result. Design your workflow to handle repeats, missing updates, and temporary failures.
Use shipment stage to choose a polling interval
Checking every shipment at the same frequency is often wasteful. A label that has not received its first carrier scan may remain unchanged for a while. A shipment marked out for delivery is more time-sensitive, so more frequent checks may be useful during the delivery window.
The schedule below is an illustrative starting point, not a carrier requirement or a promise about when scans appear. Adjust it to the carriers and services you use, your provider’s limits, your request budget, and the value of a faster update to your customers.
| Shipment stage | Example check schedule | Why it may fit |
|---|---|---|
| Label created or awaiting carrier handoff | Once or twice per day | There may be little new information before the carrier accepts and scans the parcel. |
| In transit | About four times per day | Periodic checks can reveal movement while keeping requests bounded. |
| Out for delivery | Every one to two hours during the expected delivery window | More frequent checks can make delivery progress more timely for customers and operations. |
| Delivered, cancelled, or otherwise complete | Stop routine polling | Keep the final result and only check again if your workflow has a reason to reopen monitoring. |
Use the latest available status and events to move a shipment between schedule groups. Since carrier status labels vary, map the values your tracking provider returns into a small set of internal stages. If the status is missing or unfamiliar, use a conservative default and keep the original text for troubleshooting.
Budget the requests before increasing frequency
Polling makes usage easy to estimate. For example, 1,000 active shipments checked four times a day create about 4,000 requests per day before retries or manual refreshes. If all 1,000 are checked every hour, that becomes 24,000 requests per day. Calculate the total across your active shipments before choosing intervals.
- Use each shipment’s stage to schedule only the checks it needs.
- Spread requests across the day to avoid bursts and respect rate limits.
- Use bounded retries with backoff for timeouts and temporary errors.
- Compare new events with saved events so repeated responses do not trigger duplicate customer messages.
- Stop routine checks after a terminal status such as delivered.
Check your API provider’s quota, rate limits, caching behavior, and carrier-specific terms. A successful API response does not necessarily mean the carrier generated a new scan since the previous request.
When webhooks are available, you can combine both
Webhook and polling do not have to be mutually exclusive. A webhook can provide the primary event signal, while an occasional scheduled check can reconcile shipments if your application needs a safety net. That design adds complexity, though: make event processing idempotent, verify incoming callbacks, and ensure reconciliation checks do not exceed your request limits.
If a carrier does not provide a usable webhook, polling remains a straightforward fallback. Start with a modest interval, increase checks for time-sensitive stages such as out for delivery, and measure whether the additional requests produce useful updates for your workflow.
Choose the pattern your carrier coverage supports
Use webhooks when the provider can reliably deliver the events you need and your application can safely receive them. Prefer scheduled polling when webhook coverage is missing or inconsistent, or when you want direct control over how often shipments are checked. A stage-based schedule helps balance timely visibility with API usage.