DHL Express: Production rejected for karrio

[MarcoWel]

In order to use karrio with DHL Express, they need to approve the user for production use.
This requires us to create three test shipment labels via karrio:

• DOM (Domestic Express, e.g. DE->DE)
• ECX (Express Wordwilde EU, e.g. DE->NL)
• WPX incl. CIN/PLT (Express Worldwide with Paperless Trade, e.g. DE->US)

Unfortunately we got rejected for the following reasons:

• MetaData.SoftwareName = "3PV" - should be karrio, seems hardcoded here
• AddressLine1 = "1 Teststr." - should be Teststr. 1 (address_line1 = "Teststr. 1" was stated within karrio correctly)
• DOM: ShipmentDetails.LocalProductCode = "N" - should be E
• ECX: ShipmentDetails.LocalProductCode = "W" - should be V
• WPX: ShipmentDetails.LocalProductCode = "P" - should be S
• (API is still xmlPI, they recommend switching to REST API soon - only a recommendation at this point, not a reason for rejection yet)

Could you correct the LocalProductCode for the services accordingly?
Or is the service definition moving to the rate sheet editor soon (new services.csv here)?

[Dan (danh91)]

Hi MarcoWel,
Thanks for sharing that. Ansh dev nagar (@Ansh-Dev-Nagar) would be great to prioritize this one.

• SoftwareName should be added to the connection config (MarcoWel, this cannot be defaulted to karrio because it is not universally certified by DHL as a compatible integration partner)
• AddressLine1 should be further investigated

I fear changing this will be more complex, as it seems inconsistent between North America and the EU, but I'm not too sure.

DOM: ShipmentDetails.LocalProductCode = "N" - should be E
ECX: ShipmentDetails.LocalProductCode = "W" - should be V
WPX: ShipmentDetails.LocalProductCode = "P" - should be S

In general, Ansh dev nagar (@Ansh-Dev-Nagar) is getting mydhl, which is the new DHL Express Rest API production-ready. I think it will be a better effort spent on him finishing testing it should be in the next 2 days, and you can submit the Rest API instead for certification.
We would be grateful if you could share your experience and help get it approved

[MarcoWel]

Thank you! We got reply from DHL Express that they "strongly advise" to use REST API for new production requests.
We can help you getting issues solved and keep you posted - would be great to have the REST API ready soon!

For the street names, most European countries have "Test Street 1" except FR, GB and IE which are "1 Test Street".
Little help of ChatGPT:

Europe — Style 1 (<Street> <Number>)

ISO	Country	Format	Example	Notable Special Cases
AT	Austria	<Street> <Number>	Mariahilfer Straße 45	Apartments 12/3/4 (house/staircase/apartment)
BE	Belgium	<Street> <Number>	Rue de la Loi 16	Apartment box (16 bus 3)
CH	Switzerland	<Street> <Number>	Bahnhofstrasse 10	Letter suffix (10a)
DE	Germany	<Street> <Number>	Hauptstraße 12a	Letter suffix (12a), ranges (12–14)
DK	Denmark	<Street> <Number>	Nørrebrogade 24	Floor + side (3. tv.)
ES	Spain	<Street> <Number>	Calle Mayor 12	Floor + door (12, 3ºB)
FI	Finland	<Street> <Number>	Mannerheimintie 12	Staircase + apartment (12 A 4)
IT	Italy	<Street> <Number>	Via Roma 21	Scala B, Int. 4, red numbers in some cities
NL	Netherlands	<Street> <Number>	Keizersgracht 123	Apartment suffix (123-A, 123 bis)
NO	Norway	<Street> <Number>	Karl Johans gate 15	Letter suffix (15B)
PT	Portugal	<Street> <Number>	Rua Augusta 50	Floor + side (50, 3º Esq.)
SE	Sweden	<Street> <Number>	Storgatan 8	Apartment numbers sometimes separate (1101)

Europe — Style 2 (<Number> <Street>)

ISO	Country	Format	Example	Notable Special Cases
FR	France	<Number> <Street>	10 Rue de Rivoli	bis, ter suffix (10 bis)
GB	United Kingdom	<Number> <Street>	221B Baker Street	Letter suffix (221B), building names possible
IE	Ireland	<Number> <Street>	12 O'Connell Street	Building names common

Rest of World

ISO	Country	Format	Example	Notable Special Cases
AU	Australia	<Number> <Street>	15 George Street	Unit prefix (Unit 5/15)
CA	Canada	<Number> <Street>	24 Sussex Drive	Unit prefix (Unit 5 – 123)
CN	China	<Number> <Street>	1 Chang’an Ave	Building/room numbers
JP	Japan	Block system	2-3-1 Asakusa	<district>-<block>-<building>
NZ	New Zealand	<Number> <Street>	33 Queen Street	Unit prefix (5/33)
US	United States	<Number> <Street>	1600 Pennsylvania Ave	Apt, Suite, Unit

[Ansh dev nagar (Ansh-Dev-Nagar)]

Hi MarcoWel,

Thanks for the detailed breakdown of address formats, very helpful! We're already working on fixes for the issues reported here. The AddressLine1 formatting is being fixed to preserve the original input as provided, so it will work correctly for all country formats (both Style 1 and Style 2). The SoftwareName will also be made configurable via connection settings.

Regarding the REST API, we're actively getting MyDHL (the REST API) production-ready and it should be available soon.

Will keep you posted!

[MarcoWel]

2026.1.21:

• SoftwareName: unchanged
• AddressLine1: fixed!
• ProductCode: unchanged - awaiting info from DHL Express regarding a code overview

As soon as the product code is fixed, we can apply for getting the xmlPi into production.
When that is done, we can get the REST API into production as soon as it is done from your side.

[Ansh dev nagar (Ansh-Dev-Nagar)]

Hi MarcoWel,

The SoftwareName is actually configurable as of 2026.1.21!

If you go to your DHL Express connection settings, you'll see a new "Software Name" field under the Credentials tab.

Why it appears unchanged:

• If the field is left empty, it defaults to "3PV"
• You need to explicitly set it to the value DHL has assigned to you

Steps:

1. Go to Connections → Edit your DHL Express connection
2. Under Credentials, find the Software Name field
3. Enter your DHL-assigned software name
4. Click Save

Let us know if you're able to set the Software Name from your connection settings!

[MarcoWel]

We received the following info from DHL Express:

You can find the corresponding codes in the table below. The local product code is often not transmitted; however, if it is provided, it must be correct to avoid incorrect postings.

	Productname	ServiceType (Global NW Type)	GLOBAL PRODUCT CONTENT CODE	CONTENT	Declared Value	ServiceType (Local NW Type)
National Express (non-dutiable)	DOMESTIC EXPRESS 9:00	I	DOK	DOCUMENTS	no	H
	DOMESTIC EXPRESS 10:30 (ex 10:00)	O	DOL	DOCUMENTS	no	O
	DOMESTIC EXPRESS 12:00	1	DOT	DOCUMENTS	no	L
	DOMESTIC EXPRESS	N	DOM	DOCUMENTS	no	E
Internat. Express Doc (non-dutiable)	EXPRESS ENVELOPE	X	XPD	DOCUMENTS	no	X
	EXPRESS WORLDWIDE	D	DOX	DOCUMENTS	no	D
	EXPRESS 9:00	K	TDK	DOCUMENTS	no	K
	EXPRESS 10:30 (only to USA)	L	TDL	DOCUMENTS	no	J
	EXPRESS 12:00	T	TDT	DOCUMENTS	no	T
	EXPRESS WORLDWIDE	U	ECX	DOCUMENTS	no	U
Internat. Express Non-Doc (dutiable)	EXPRESS 9:00	E	TDE	NON_DOCUMENTS	yes	G
	EXPRESS 10:30 (onty to USA)	M	TDM	NON_DOCUMENTS	yes	M
	EXPRESS 12:00	Y	TDY	NON_DOCUMENTS	yes	Y
	EXPRESS WORLDWIDE	P	WPX	NON_DOCUMENTS	yes	S
Economy Select	ECONOMY SELECT EU	W	ESU	DOCUMENTS	no	V
	ECONOMY SELECT NON-EU	H	ESI	NON_DOCUMENTS	yes	N

[MarcoWel]

Dan (@danh91) Ansh dev nagar (@Ansh-Dev-Nagar) Could you either remove the ShipmentDetails.LocalProductCode or adjust it to the correct codes shown in the last column of above table? This is the main issue of not getting production confirmation from DHL Express.

Currently LocalProductCode is set to GlobalProductCode in karrio which is incorrect:

karrio/modules/connectors/dhl_express/karrio/providers/dhl_express/shipment.py

Lines 446 to 447 in f19fe20

	GlobalProductCode=product,
	LocalProductCode=product,

[Ansh dev nagar (Ansh-Dev-Nagar)]

Hey MarcoWel,

Thanks for getting this detailed product code mapping from DHL Express

We're looking into the LocalProductCode issue and will most likely remove it from the requests entirely. Will keep you posted on the progress!

[MarcoWel]

Ansh dev nagar (@Ansh-Dev-Nagar) Happy to report that the LocalProductCode issue is fixed with 2026.1.26 and we could continue production review with DHL Express (they will still allow xmlPi until it is officially retired).

Labels look good now with one exception that DHL refuses:
karrio always sends N/A for PlaceOfIncoterm which makes international shipments (WPX) fail!
<PlaceOfIncoterm>N/A</PlaceOfIncoterm>

It is hardcoded here:

karrio/modules/connectors/dhl_express/karrio/providers/dhl_express/shipment.py

Line 368 in 96972ac

PlaceOfIncoterm="N/A",

It should be sufficient to set PlaceOfIncoterm=recipient.city for most cases.

More info

Incoterm definitions:
https://mydhl.express.dhl/us/en/shipment-settings/terms-of-trade-definitions.html

Dashboard screenshot: