Use a Track123 webhook to receive DPD tracking updates at your application instead of relying only on scheduled polling. A webhook is especially useful for order-status notifications, exception handling, customer-support workflows, and dashboards that should update when a new carrier event is available.
This is a Track123 integration guide. It describes Track123's unified webhook delivery flow and is not official DPD webhook documentation.
-
Register the shipment with Track123.
-
Include
courierCode: "dpd"when DPD is already known. -
Use Carrier Detection if a confirmed carrier code is unavailable.
-
Configure an HTTPS endpoint in Track123 for tracking notifications.
-
Receive an HTTP POST when Track123 delivers a tracking event.
-
Verify the request signature, identify the tracking record, and safely update your own system.
-
Return a 2xx response only after your application has accepted the delivery.
The webhook should complement—not replace—your own data model. Store the tracking number, your order identifier, the latest normalized status, and enough event metadata to diagnose delivery or reconciliation issues.
Do not treat an incoming request as trustworthy merely because it reaches your endpoint. Track123's webhook guide documents signing with your Track123 API key and a plain-text timestamp. Verify the signature included in the POST data before acting on an event.
The public guide specifies SHA256 for PHP and HmacSHA256 for Java examples. Use the current Track123 webhook guide for the exact payload, signature field, and language-specific verification approach.
A safe server-side handling sequence is:
- Accept the request over HTTPS.
- Read the raw request data and timestamp needed for signature verification.
- Recalculate and compare the signature using your server-side Track123 API key.
- Reject an invalid signature without changing order state.
- Use a stable event or tracking-record identifier to prevent duplicate processing.
- Persist the accepted update and then respond with a 2xx status.
Never expose the API key in client-side JavaScript, a mobile application, or a public repository.
When Track123 does not receive an HTTP status from 200 through 299, it may retry a webhook delivery up to seven times. The documented schedule is shown below; build idempotent processing because more than one delivery can represent the same update.
| Delivery attempt | Delay before the attempt |
|---|---|
| 1 | Immediate |
| 2 | 10 minutes |
| 3 | 30 minutes |
| 4 | 1 hour |
| 5 | 4 hours |
| 6 | 12 hours |
| 7 | 36 hours |
If your service temporarily cannot process an event, return a non-2xx response only when a retry is appropriate. Avoid deliberately failing requests for permanent validation errors, because it creates repeated deliveries without resolving the underlying issue.
Webhook events can arrive more than once, and carrier event order may not always match the order in which your application processes requests. Use a deduplication key and make state changes safe to repeat. For example, do not send a second “delivered” customer notification just because a delivery event is received again.
Keep the original tracking data and the latest processed timestamp in your system. If a later query result and a webhook appear inconsistent, use the Get package trackings endpoint and the Track123 status references to reconcile the record.
-
Confirm the tracking number was registered successfully.
-
Use the carrier code
dpdwhen registering known DPD shipments. -
Use a stable, public HTTPS endpoint with server-side signature verification.
-
Return a 2xx response only after persistent processing succeeds.
-
Protect against duplicated delivery and out-of-order updates.
-
Monitor failed delivery, authentication, and processing errors.