Shipping & carrier APIs

Carrier integration is where a marketplace build stops being about data and starts being about physical objects. Every successful call books something real: a label that gets billed, a courier who turns up at a door, a customs declaration filed under your client's name. The tooling is a generation behind the marketplace APIs sitting beside it in the same codebase — SOAP envelopes, positional fields, responses that are not XML — and on the India export lane there is no sandbox at all, so the first genuine test is production.

The order this work happens in

Across the five guides below the same sequence keeps proving itself, ordered by how much damage a wrong call can do:

• Rate quote first. It books nothing, which makes it the safe place to prove credentials, envelope construction and response parsing.
• The single label. The headline integration, and the call that files real paperwork.
• Documents. The commercial invoice and the customs fields that decide whether a shipment clears or sits.
• Consolidation. Many parcels under one master airway bill instead of one shipment each.
• Pickup. A label nobody collects is not an operation.

Which guide covers which part

Start with the label, because everything else on the India lane assumes it exists. What CSB-V is, and the four behaviours that defeat ordinary SOAP tooling covers the 142 positional fields, responses that come back as delimited strings rather than parseable XML, and the missing sandbox that makes your first successful call a real customs filing. Once that works, two smaller operations turn it into a daily process: a rate quote that books nothing and a pickup request that gets a courier to the door, with the conventions that apply across all of these SOAP calls.

Consolidation is the piece most teams assume they cannot automate, and on these two carriers they are wrong twice over. DHL India exposes mother-baby consolidation as a real SOAP operation — one master airway bill, many children, no desktop app and no manual data entry in the loop. On FedEx, the same capability is already inside the Ship API you call for single labels, as Open Ship, along with the four things the documentation glosses over.

Documents get their own guide because the API is the easy half. Electronic Trade Documents and the customs fields that actually cause holds covers what ETD replaces — the printed invoice in a plastic wallet — where it sits in the request, the four fields worth being pedantic about, and the cancel path, which matters the moment you automate label creation.

None of these came out of reading documentation for its own sake. Each is a lane built and run for a client, which is why they spend as much time on operating habits as on request shapes: keep the risky path behind a flag until you have seen a real response, and treat the first live call as the test, because on these lanes it is. The field names change with every carrier. Those habits don't.