DHL India CSB-V: The SOAP API That Returns a Delimited String

If you export commercial goods from India by courier, you file a Courier Shipping Bill. CSB-V is the electronic commercial variant, filed into Indian customs' ECCS system, and it's what lets a seller export goods as a proper commercial shipment — with the export documentation and incentives that follow — rather than as a gift or sample.

For a marketplace seller shipping from India to buyers abroad, that's not optional paperwork. It's the difference between a compliant export operation and one that will eventually have a problem.

The API side is where it gets interesting. This is not a modern REST shipping API. It's SOAP, it's positional, and it behaves in several ways that will defeat your usual tooling if you don't know about them first.

1. Every response is a delimited string, not XML.

This is the headline. You'd expect a SOAP operation to return a structured response you can navigate with an XML parser. Instead the meaningful payload comes back as a single string field containing delimited values embedded inside the SOAP envelope. Your parser sees one string; everything you actually need — the waybill number, the status, the error text — is inside it.

<PostShipment_CSBVResult>SUCCESS|1234567890|…|…</PostShipment_CSBVResult>

Which means you are string- and regex-parsing the response, and you must handle the case where the shape of that string differs between success and failure. Write a parser that fails loudly on an unrecognised shape rather than returning None — a silently unparsed error response is how a failed booking gets recorded as a success.

2. The SOAPAction contract name must be exact, and a wrong one is silently rejected.

Each operation is addressed by a contract-qualified SOAPAction. Get the contract name wrong and the call doesn't error usefully — it's simply rejected. Take the contract name from the WSDL and centralise it as a constant; do not let it be assembled ad hoc in more than one place.

3. The create-shipment operation is 142 flat fields, in WSDL order.

Not a nested document — a flat positional envelope, and the order matters. Practically this means the envelope belongs in one place in your codebase, built from a single ordered definition, with tests that assert field order. It also means one line item per call: multi-item shipments need the value aggregated into the fields the envelope provides rather than repeated blocks.

4. There is no sandbox.

Covered below, because it deserves its own section.

There is no UAT environment. The base URL is the live host. A successful call files a real CSB-V declaration with Indian customs and books a real shipment.

That changes how you build. The safety mechanism has to live in your own code:

The design that works: a dry-run flag that defaults to on, intercepting after the envelope is fully constructed and before the network call. That way your test suite exercises all 142 fields, the ordering, the value placement and the trimming rules, and asserts on the exact envelope — without ever touching customs. Then a small number of deliberate live bookings validate the response parsing.

Unlike a domestic label API, CSB-V needs export-compliance identifiers that belong to the exporting business and take time to obtain. Collect them before you write the integration, because a missing one blocks you completely:

• IEC — the Importer Exporter Code for the exporting entity.
• GSTIN — and note that this needs to actually fit in the address blocks on the printed documents. Long registration numbers plus a long address is a real overflow problem on commercial invoices, and truncation of a tax number on an export document is not a cosmetic bug.
• AD code — the authorised-dealer code tying the shipment to the bank handling the foreign exchange.
• HS codes per product, at the digit-count the carrier expects. Different carriers want different lengths, and sending the wrong number of digits is rejected at booking.
• A paperless-trade signature image, if you're filing electronically. Use the real one — sample signatures from integration guides sometimes carry visible test watermarks that will render onto a live document.

Three habits that transfer to any carrier integration, not just this one:

• Assume the response format is worse than documented. Delimited strings, embedded payloads and inconsistent error shapes are common in logistics APIs, which are frequently much older than their documentation implies. Write parsers that validate rather than assume, and log the raw response.
• Default to dry-run, always. When the production endpoint is the only endpoint, the safety has to be yours. Make it the default, and make disabling it a deliberate configuration act.
• Test the envelope, not the round trip. The part you'll get wrong is field construction, and that's fully testable offline. Save live calls for validating the response parsing, which is the only part you genuinely can't simulate.

What is CSB-V?

CSB-V is the electronic commercial variant of India's Courier Shipping Bill, filed into the customs ECCS system. It is the route used to export commercial goods from India by courier, as distinct from shipping them as gifts or samples.

Does the DHL India CSB-V API return XML?

Not usefully. The SOAP envelope wraps a result field whose contents are a delimited string rather than structured XML, so integrations end up string-parsing the response. Build a parser that raises on an unrecognised shape rather than returning empty.

Is there a sandbox for CSB-V?

No. The base URL is the live host and a successful call files a real declaration and books a real shipment, so safety has to come from a dry-run flag in your own code that intercepts before the network call.

What identifiers do I need to file a CSB-V shipment?

At minimum the exporter's IEC, GSTIN and AD code, HS codes for each product at the digit count the carrier expects, and a paperless-trade signature image if filing electronically.

What happens if I book a test shipment and never send it?

The declaration is filed and then lapses if the parcel is never handed over. It is not harmless — decide in advance who monitors and handles lapsed test bookings before making your first live call.