Status Mapping: Bridge (UK) → Global Tracking

Bridge (tracking.inpost.co.uk) is InPost's legacy UK-only tracking API. It returns a parcel's status as a scan_code (e.g. PRD) tied to a fixed set of UK depot/hub/locker scan events.

Global Tracking is InPost Group's unified tracking system, replacing market-specific tracking APIs like Bridge with a single, cross-market event model. Instead of a scan_code, GT emits versioned event codes (e.g. CRE.1001) that are consistent across every market InPost operates in.

Who is it for?

If your integration currently polls Bridge or parses its scan_code values, migrating means switching to GT's Tracking API and/or webhooks, and updating any logic keyed on Bridge codes to use GT event codes instead. Migrating gets you:

• Cross-market consistency — the same event codes and tracking history format regardless of origin or destination market.
• Webhook support — real-time event delivery instead of polling.
• Longer retention — parcel history is retained for up to 121 days via GT, versus Bridge's shorter window.
• End-to-end RTS tracking — Return to Sender parcels are tracked under their original outbound tracking number.

This guide maps every Bridge scan_code to its corresponding GT event code(s), so you can update your integration's status-handling logic. Some GT events map to more than one Bridge code depending on context. Check the Condition column for these rows.

Mapping

Bridge codes without a Global Tracking equivalent

The following Bridge scan_code values are internal depot/hub scan states with no corresponding GT event. If your integration currently reacts to any of these, it will not receive an equivalent event after migrating — you'll need to adapt that logic or remove its dependency on these signals.