Visit Website →
← Back to blog

Courier Tracking Integrations for DevOps: Deduplication & Ordering

September 29, 2026
Courier Tracking Integrations for DevOps: Deduplication & Ordering

Subscribe to courier webhooks as your primary data source, and reserve polling for backfill or for carriers that lack push support. Pair this with a multi-carrier aggregator if you need one endpoint across many carriers, and route every event through a resilient ingestion service that enforces deduplication and orders events by occurredAt. Your next step: register a secure webhook endpoint and move it from test to production in a staging environment before you touch live shipments.

TL;DR:

  • Webhooks are preferred for real-time shipment updates due to their lower infrastructure load, but polling still plays a role in backfill and non-supported carriers.
  • Implementing a resilient ingestion service involves verifying signatures, deduplicating events, ordering by occurrence time, and logging all data to ensure accuracy and reliability.
  • Carrier-specific data offers deep insights but requires ongoing maintenance, while aggregators provide normalized statuses that accelerate deployment across multiple carriers.
  • Use an order of magnitude staleness window to prevent delayed webhook events from regressing shipment statuses, and enforce strict security with HTTPS and signature validation.
  • Building in-house integrations is justified for critical data requirements, but scaling is easier with multi-carrier platforms, especially when supporting numerous shipments or carriers.
Simplyparcel
Simplify Multi Carrier Tracking
Compare and book international courier services, with online labels, documentation, and real time shipment tracking in one platform.
Explore Simply Parcel

Table of Contents

How webhooks and polling differ, and when to use each

Webhooks push shipment events to your endpoint the moment a carrier records a status change. Polling pulls data by repeatedly calling a carrier's API on a schedule, whether anything has changed or not.

The difference shows up quickly in production. Webhooks deliver near-real-time updates with far less infrastructure load, since your servers only work when there is something to process. Polling burns API calls, hits rate limits faster as your shipment volume grows, and introduces a lag equal to your polling interval. Automating tracking this way has been shown to cut manual tracking work by about 65% and reduce "where is my order" support calls by roughly 40 to 63 percent, which is why webhooks are the standard for production systems.

The practical answer is not either/or:

  • Use webhooks as your primary truth stream for live status changes.
  • Use polling for periodic reconciliation, catching events a webhook missed.
  • Use polling for backfill when a carrier has no push support or your endpoint was briefly down.
  • Check carrier documentation for push notification support before building a polling-only integration.

Some carriers, including options covered in Amazon's shipping tracking documentation, offer push notifications directly, while aggregators typically support both mechanisms so you are not locked into one pattern.

Architectural pattern: building a resilient ingestion service for courier events

A tracking integration is only as reliable as the service that receives its events. Courier webhooks arrive duplicated, delayed, and occasionally out of order, so your ingestion layer has to assume the worst and correct for it.

  1. Expose an HTTPS endpoint that verifies each incoming payload with an HMAC-SHA256 signature before touching the data.
  2. Respond with a 202 Accepted immediately, then hand the payload to an async queue for processing.
  3. Deduplicate using a database UNIQUE constraint on (partner, eventId) where the carrier provides a stable ID, and fall back to a content hash such as SHA256(partner, shipmentId, status, occurredAt) when it does not, a pattern detailed in ShipmentLedger's ingestion design.
  4. Trust occurredAt, not arrival time, as the authoritative clock for ordering events, since webhook delivery is not guaranteed to arrive in order.
  5. Write every event to an immutable audit log, then update a separate materialized Shipments table with only the latest state.

Pro Tip: Add a staleness window that rejects any incoming event whose occurredAt is older than your current stored state, so a delayed or misbehaving carrier feed cannot regress a shipment backward.

Wrap the state update in a transaction, retry failed queue jobs with exponential backoff, and expose a health endpoint so you catch a broken webhook subscription before your support queue does.

Illustration of resilient event ingestion flow

Integration options and trade-offs: carrier APIs vs aggregators vs unified tracking platforms

Three paths lead to the same destination, and the right one depends on how many carriers you touch and how deep you need the data to go.

  • Direct carrier APIs give you the richest data, including proof-of-delivery photos and location coordinates, but each carrier has its own schema, auth method, and webhook format, which turns into a maintenance job as you add lanes.
  • Multi-carrier aggregators, including options built on providers like Singapore Post's tracking API, normalize statuses into one vocabulary and cut rollout time to days instead of months, though you should verify coverage on your specific carrier lanes before committing.
  • Unified order-tracking platforms extract tracking numbers directly from a retailer's order confirmation and fire their own webhooks, such as order.tracking_received, which suits teams that never receive a tracking number in the first place.

Before choosing, answer three questions: do you already hold tracking numbers today, what shipment volume and latency does your SLA demand, and do you need retailer extraction or a branded tracking page for your customers. A side-by-side look at courier integration approaches can help map these questions to your existing stack.

Data model and status normalization: what to capture and how to map carrier statuses

Every carrier describes the same five or six shipment states with a different word, so your first engineering task is building one vocabulary that the rest of your system can trust.

Capture these fields on every event: shipmentId, trackingNumber, partner, eventId, status, occurredAt, location, and a proofOfDelivery field holding a URL or metadata when the carrier provides it. Many modern tracking APIs attach proof-of-delivery data as optional metadata on push events, so your schema should treat it as present-but-optional rather than guaranteed.

Map every carrier-specific string to one of these canonical statuses:

  • pending: booked but not yet scanned by the carrier
  • in_transit: moving between facilities
  • out_for_delivery: with the final-mile courier
  • delivered: confirmed at destination
  • exception: delayed, damaged, or held at customs
  • undelivered: delivery attempted and failed

Keep the full checkpoint history in your audit log even after a shipment is delivered, and derive the current-state snapshot from whichever stored event has the latest occurredAt. Expose that normalized state through both a pollable shipment object and your own downstream webhooks, a structure covered in more depth in our guide to tracking shipments across carriers.

Operational best-practice checklist for production reliability

Most tracking integration failures trace back to one of five gaps, and each has a straightforward fix.

  1. Require HTTPS on every webhook endpoint, validate the HMAC signature on every payload, and rotate your shared secret on a fixed schedule.
  2. Enforce idempotency at the database level, not in application code, and return a distinct response code for a detected duplicate so your logs can separate real errors from expected repeats.
  3. Define a backfill policy with a fixed lookback window and polling frequency, then run it on a schedule regardless of whether webhooks appear to be working.
  4. Monitor webhook success rate, queue depth, and SLA breaches, and track whether the integration is actually reducing "where is my order" contact volume.
  5. Retain your immutable event store long enough to replay and reconstruct any shipment's history when a customer or a carrier disputes a delivery outcome.

Pro Tip: Alert on a drop in webhook volume, not just on errors. A carrier can silently stop sending events without ever returning a failed request.

Handling tracking data also means handling personal information such as recipient addresses and delivery photos, so apply the same access controls and retention limits you use elsewhere in your systems, and review them against regulations like GDPR if any shipments touch the European Union.

Simply Parcel's approach to multi-carrier tracking integration

Simply Parcel connects to multiple major courier partners through one platform, so a shipment booked through the service surfaces real-time tracking without a separate integration per carrier. Labels and customs documentation generate automatically at booking, and pickups are scheduled without a manual back-and-forth. For teams applying the patterns above, a practical starting experiment is enabling webhooks in a sandbox workspace, confirming HMAC verification works end to end, and running a short backfill poll against a handful of test shipments before going live. Our breakdown of how tracking improves shipping outcomes walks through this in more detail.

When to build in-house versus use a platform or aggregator

Building your own carrier integrations makes sense when you need carrier-specific data like signature capture or exact delivery coordinates, and your team has the capacity to maintain a growing list of carrier-specific webhook formats. Most teams do not have that capacity indefinitely, which is why buying access through an aggregator wins on time-to-market once you are past a handful of carriers. The pattern that holds up over time is usually hybrid: an aggregator handling the bulk of carriers, with direct integrations reserved for the one or two lanes where deeper data actually changes a business outcome. Our roundup of courier platforms is a reasonable starting point for weighing that trade-off against your own volume.

— Simply

How Simply Parcel supports your shipping and tracking workflow

If you are choosing between building carrier integrations from scratch or working with a platform that already connects to multiple courier partners, Simply Parcel removes the integration overhead entirely. Booking a shipment through Priority, Connect Plus, or Economy shipping gives you real-time tracking, auto-generated labels and customs documentation, and free pickup at the sender's doorstep, without a monthly volume commitment holding you to a contract you don't need. Rates stay transparent at the point of booking, so there is no separate negotiation before you can compare options.

If you want to see rates and transit times for an upcoming shipment, get a shipping quote and compare your options directly, or read more about the company behind the platform before you book your first parcel.

Sources

FAQ

What is the difference between webhooks and polling for tracking?

Webhooks push a shipment event to your system the moment it happens, while polling requires your system to repeatedly ask a carrier's API whether anything changed. Webhooks reduce latency and server load and are the standard for production tracking, while polling remains useful for backfill and for carriers without push support.

How do you prevent duplicate tracking events from breaking shipment status?

Enforce a database UNIQUE constraint on the carrier's event ID when one exists, and use a content hash of the partner, shipment ID, status, and occurredAt fields when it does not, a pattern detailed in ShipmentLedger's ingestion design. This makes retried or duplicated webhook calls harmless instead of corrupting your shipment state.

Why should events be ordered by occurredAt instead of arrival time?

Webhook delivery is not guaranteed to arrive in the order events actually happened, so trusting arrival time can regress a shipment to an earlier state. Ordering by occurredAt keeps the shipment timeline accurate even when a carrier's network delays one event behind another.

How do you secure a webhook endpoint for courier tracking?

Require HTTPS on the endpoint and validate every incoming payload against an HMAC-SHA256 signature using a shared secret. Rotate that secret on a regular schedule and reject any payload that fails verification before it reaches your processing queue.

Should I use a carrier API directly or an aggregator?

A direct carrier API gives you the deepest data, such as proof-of-delivery photos and precise location coordinates, but becomes a maintenance burden once you support several carriers. An aggregator normalizes statuses across carriers into one API and speeds up rollout, though you should confirm it covers your specific carrier lanes before switching over.