Whilst all couriers in Shiptheory work the same way regarding courier services - each service has a name and a code - DX Express services are a bit different.


This document aims to help explain how Shiptheory and DX Express work together, why the courier service codes for DX Express have ended up the way they are and what to do should a customer receive a "'XXX' is not a valid service for this shipment" error message.



A Basic Explainer

In short, unlike all other couriers, DX Express don't have service codes for each of their courier service offerings. Instead, they have a set of services from which, when services are assigned to their customers they are given a service name (or description) which, ideally, should conform to a set standard. In reality, this isn't always the case.


When a customer books a shipment in Shiptheory, an initial Get Services request is sent querying from DX which services on the customer's account are valid for the shipment's destination. A list of services is returned containing the service descriptions and Shiptheory looks to find the code of the service selected in Shiptheory in that list of descriptions. If a match is made, the shipment is booked. If a match cannot be made, it's assumed an invalid service has been selected and a "'XXX' is not a valid service for this shipment" error is returned.


The difficultly is that, in reality, the service names or descriptions assigned by DX are not consistent and vary, in some cases, quite wildly.



Shiptheory Service Codes

The basic DX Secure services are Leave Safe, Mandatory Signature and Signature. For each of these there is a standard, Box, Bag and Length variant and within each of those variants are 24 hour, Pre 12 pm, Pre 1 pm, Saturday, Saturday AM, Rural (2 day & 3 day) and Northern Ireland (24 hour & 3 day) options.


There are a couple of DX Courier and legacy services but this covers the services that should be available to customers.



The difficulty in matching Shiptheory service codes with the service descriptions from DX is that whilst DX claim to attempt to have standard service descriptions, this often isn't the case. Consider the three descriptions below in Shiptheory for the "DX Secure: Signature Length, Pre 12:00" service:


  • %% Signature Length, 24 Hour, Signature, Pre 12pm
    %% is a placeholder for the customer's DX account company name which is, in some cases prepended to the service descriptions.

  • Signature Length 24, 24 Hour, Signature, Pre 12pm
    This description varies from the first, not just in that there is no company name placeholder at the start, but also note the additional "24" after "Length" before the first comma.
  • Signature Long 24, 24 Hour, Signature, Pre 12pm
    In some cases, "Long" has been used instead of "Length". It's been confirmed by DX that Length and Long are the same service. Note: In some cases, just an "L" may be used



Since there is no "one-size fits all" solution to cope with these variances, arbitrary service codes have been assigned to each of the DX services that map to a class in the Shiptheory code containing all of the "known" descriptions for each service we have come across so far.


When Shiptheory comes to check the Get Services response, each of the descriptions stored in code for the service code selected by the customer is compared against each of the services in the list returned from DX.



'XXX' is not a valid service for this shipment

If a customer is receiving this error and has 100% confirmed that they have selected the correct shipping method in Shiptheory and that service has been added to their account by DX, the issue should be escalated to the Dev team with a copy of the GetServices data from their shipment in Shiptheory and details of the service they're trying to book with.


A member of Dev can then extract the service descriptions from the Get Services response and compare them against the description(s) stored in Shiptheory for the corresponding courier service.


Using the guide above (Shiptheory Service Codes) it should become clear whether:

  • The customer has a "new" description variant for a service we have in our database and we need to append a new description to the current service code, separated by a | (pipe)
  • This is a new service that needs to be added to our database.
  • The code already exists in the Shiptheory database but the customer has simply selected the wrong service.




It's better to be safe than sorry. If any of this is not clear or you are not sure about something, please ask someone in the Dev team!