Integrating a shipping carrier is not an API mapping problem. It's a state problem you don't control.
Every carrier exposes its own status vocabulary, and the naive move is to map each one onto your own enum and call it done. That works until you run several carriers at once. Then you learn that events arrive out of order, that a shipment can move backwards from out-for-delivery to in-transit, that some carriers repeat a status for days and others go silent for a week, and that delivered is not terminal because a return can reopen the whole thing weeks later.
What I ended up doing on cross-border delivery pipelines: store the raw carrier event exactly as received, with its own timestamp, and treat it as an append-only log. Derive my status from that log rather than overwriting a status column. Order by the carrier's event time, not arrival time. And keep an explicit unknown state instead of forcing every foreign status into a bucket that looks tidy but lies to support and to the customer.
The rule I'd keep: never let an external system write directly into your state field.
For those running multi-carrier shipping — what broke first for you: status mapping, silent gaps, or returns after delivery?