Intelligent Shipper API - Multipiece Shipment Bookings v1.7.17
API Version: 1.7
Document Version: 1.7.17
Document Owner | INTERSOFT Systems and Programming Limited |
Version | 1.7.17 |
Date | 15/09/2023 |
Description | Describes how to integrate with the Intelligent Shipper Shipment Booking API |
Author | Laura Price |
Commercial and in Confidence
The information contained in this document is confidential. No part of this document may be reproduced, disclosed to any third party, or issued in any form or by any means without the express written permission of Intersoft Systems & Programming Ltd.
Contents
Introduction. 4
2.1. Implementation of the Service. 4
API Services. 5
Integration Header and Footer. 7
createShipment 9
5.2. createShipmentResponse. 21
cancelShipment. 23
6.1. cancelShipmentRequest. 23
6.2. cancelShipmentResponse. 23
confirmShipment. 24
7.1. confirmShipmentRequest 24
7.2. confirmShipmentResponse. 25
printDocument. 26
8.2. printDocumentResponse. 27
generateQRCode. 28
9.1. generateQRCodeRequest. 28
9.2. generateQRCodeResponse. 28
10.1. manifestHistoryRequest. 29
10.2. manifestHistoryResponse. 29
11.1. printManifestRequest. 30
11.2. printManifestResponse. 30
12. GetPrealloactedTrackingNumber. 31
12.1 GetPreallocatedTrackingNumberRequest. 31
12.2 GetPreallocatedTrackingNumberResponse. 31
2. Introduction
This document describes the XML interface for the Intelligent Shipper Multipiece Shipment Bookings functionality. Example XML messages for each service are provided in the document “Intelligent Shipper API – Multipiece Shipment Bookings XML Examples”.
2.1. Implementation of the Service
The service is implemented using XML messaging. The customer is responsible for sending an XML message in the format displayed in the document “Intelligent Shipper API – Multipiece Shipment Bookings XML Examples”. The customer is responsible for maintaining the capability of receiving XML messages in the format displayed in the example XML responses.
XSDs are not required, so do not exist. Communication to Intelligent Shipper endpoints will only utilise HTTPS. TLS version 1.2 (In affect from March 31st, 2020) only will be enabled. TLS cipher suites utilised on the Intelligent Shipper solution can be found via the below link for the Sandbox environment:
https://www.ssllabs.com/ssltest/analyze.html?d=test.intelligentshipper.net&latest
XMLs will be processed via Post actions. XMLs will be secured by data passed in the Integration Header portions of the XMLs provided. Intersoft will provide the required credentials via email as part of the onboarding process.
2.2. Fair Usage Policy
In order to maintain optimal performance of our API and ensure that all partners and customers have a good experience, we urge all developers to consider and optimize their calls and flows. Fair use is defined as 20,000 API calls per 24-hour period per agreement.
If an application creates an excessive load on the API, Intersoft is at liberty, without warning, to restrict the integration's access to our APIs. Intersoft will offer help and guidance on how to optimise the technical implementation.
3. API Services
The Intelligent Shipper Multipiece Shipment Bookings API contains the following services:
Service Name | Description | Mandatory / Optional | Allowed Methods | URL |
createShipment | Creates a new shipment and generates the shipping label. | Mandatory | Post | /api/v1.7/shipments/createShipmentRequest |
cancelShipment | Cancels a current shipping label for shipments that have not been confirmed. | Optional | Post | /api/v1.7/shipments/cancelShipmentRequest
|
confirmShipment | Locks down the shipment so that it can no longer be edited and generates the required collection paperwork (e.g. Manifest). | Mandatory | Post | /api/v1.7/shipments/confirmShipmentRequest
|
printDocument | Returns customs documentation for a shipment in the requested format – CN23, Proforma Invoice or Commercial Invoice. | Optional | Post | /api/v1.7/documents/printDocumentRequest
|
generateQRCode | Generates a QR code for returns shipments using Royal Mail Tracked Returns services. The QR code can then be scanned at the Post Office to generate the returns label | Optional | Post | /api/v1.7/shipments/generateQRCodeRequest |
manifestHistory | Returns details of the manifests created on a specified date. The manifest details returned in the response can then be used with the printManifestRequest to return a PDF manifest image. | Optional | Post | |
printManifest | Returns a manifest image in Base64 encoded PDF format. | Optional | Post | |
PreallocatedRMTrackingNumber | Pre-allocates a Royal Mail tracking number without creating a shipment and returns the tracking number in the response, so that it can later be used in the createShipment request when generating a Royal Mail Shipping label. | Optional | Get | /api/v1.7/shipments/getPreallocatedRMTrackingNumberRequest |
The document contains a separate section for each of these services, which describes the service in more detail including the request and response XML content.
Integration Header and Footer
The request and response header and response footer use the same format across each API service. The purpose and XML content of these header and footer sections is described below. Content unique to each service is described in the section for that service.
4.1. Request Header
The request header confirms the version number being used and denotes the UTF-8 encoding used in the service. The header confirms who the request is coming from and verifies the credentials used in the request.
The request header contains the following elements:
Element Name | Data Type | Mandatory /Conditional / Optional | Notes |
serviceNameRequest/integrationHeader | |||
<dateTimeStamp> | D–19 | O | YYYY-MM-DD HH:MM:SS Date/Time Stamp of the request. |
<transactionId> | C–32 | M | Unique identifier of the request, preserved throughout the lifespan of the transaction. This must be generated by the customer. If the API requests for a customer account are being sent one at a time, so that one transaction has been completed before the next transaction is started, then the same transactionId can be used for all requests. However if a customer account is sending multiple API requests at a time (e.g. on multiple workstations) then each request will need to have a unique transactionId – there cannot be multiple transactions with the same transactionId occurring at one time. |
<applicationId> | C–10 | M | The ID of the Service Requester calling the service. This will be provided by Intersoft. |
<userId> | C–10 | M | User ID for system access. This will be provided by Intersoft. |
<password> | C–10 | M | Password for system access. This will be provided by Intersoft. |
4.2. Response Header
The response header contains the following elements:
Element Name | Data Type | Mandatory /Conditional / Optional | Notes |
serviceNameResponse/integrationHeader | |||
<dateTimeStamp> | D–16 | O | YYYY-MM-DD HH:MM Date/Time Stamp of the response. |
<transactionId> | C–32 | M | ID preserved throughout the lifespan of the transaction, unique when combined with the applicationId. |
<applicationId> | C–10 | M | The ID of the Service Provider, unique when combined with the TransactionId. |
4.3. Response Footer
If the data in the request generated any errors, the response XML will include a footer element containing details of these.
The response footer contains the following elements:
Element Name | Data Type | Mandatory /Conditional / Optional | Notes |
serviceNameResponse/errors/errorDetail | |||
<errorCode> | C–5 | C | Error Code. Code associated with the error condition |
<errorDescription> | C–32 | C | Description of the error condition |
<errorCause> | C–4 | C | Cause of the business error (if known) |
<errorResolution> | C–50 | C | Description of the resolution and action required to correct the error |
<errorContext> | C–50 | C | Context of the business error, e.g. client or server |
Each section will only be present if any errors were generated. See the document “Intelligent Shipper API – Multipiece Shipment Bookings Appendices” for a list of all the errors that could potentially be returned for each service.
5. createShipment
The createShipment service is used to generate the final delivery label(s) for your packages.
5.1. createShipmentRequest
The createShipmentRequest contains the following sections:
· Shipper – contains the shipper address and contact details.
· Destination - delivery address and contact details – it is the shipper’s responsibility to provide accurate and concise information to ensure the best possible delivery experience for the consumer.
· Shipment Information - the package and contents being sent. It is important that accurate information is supplied to ensure correct handling by customs authorities.
· Item Information - the items being sent in the shipment. One shipment may contain multiple items. This information is used customs authorities to process clearance (where required).
Element Name | Data Type | Mandatory / Conditional / Optional | Notes |
createShipmentRequest/shipment/shipper | |||
<shipperCompanyName> | C–35 | M | Shipper Company Name. |
<shipperAddressLine1> | C–35 | M | First line of shipper address. |
<shipperAddressLine2> | C–35 | O | Second line of shipper address, if applicable. |
<shipperAddressLine3> | C–35 | O | Third line of shipper address, if applicable. |
<shipperCity> | C–30 | M | Shipper Town. |
<shipperCounty> | C–35 | O | Shipper County. |
<shipperCountryCode> | C–2 | M | 2 Digit ISO Country Code, per ISO 3166 Standard. |
<shipperPostCode> | C–10 | M | Shipper’s Postcode. |
<shipperContactName> | C–40 | O | Shipper’s Contact Name. |
<shipperPhoneNumber> | C–20 | M | Shipper’s Contact Phone. Accepts numeric characters and the following special characters only: +.()- No other special characters are accepted. |
<shipperVatNumber> | C–15 | C | Shipper’s VAT Number. Mandatory for some carriers. See the document “Intelligent Shipper Carrier Integrations and Features” for more information. |
<shipperEoriNumber> | C-18 | C | Shipper’s EORI Number. Mandatory for some carriers. See the document “Intelligent Shipper Carrier Integrations and Features” for more information. |
<shipperEmailAddress> | C–254 | O | Shipper’s Email Address. |
<shipperReference> | C–20 | M | This is used for Returns processing and is usually the shipper’s order number provided to the consumer. |
<shipperReference2> | C-20 | C | Mandatory for some carriers. See the document “Intelligent Shipper Carrier Integrations and Features” for more information. For Royal Mail shipments this must only be used to provide the eBay Virtual Tracking Number (VTN) – no other reference should be provided in this field. For all other carriers this can be used to provide any further identifiers in addition to shipper reference. See the document “Intelligent Shipper Carrier Integrations and Features” for a list of which integrations use Shipper Reference 2. |
<shipperDeptCode> | C–17 | O | Shipper’s Department Code. |
createShipmentRequest/shipment/destination | |||
<destinationCompanyName> | C–35 | O | Company name of the destination address, if applicable |
<destinationAddressLine1> | C–35 | M | Please ensure the address data is presented in line with the destination country formats. |
<destinationAddressLine2> | C–35 | O | Please ensure the address data is presented in line with the destination country formats. |
<destinationAddressLine3> | C–35 | O | Please ensure the address data is presented in line with the destination country formats. |
<destinationCity> | C–30 | M | Destination Town Name. |
<destinationCounty> | C–35 | C | Required for Australia, USA and Canada. |
<destinationCountryCode> | C–2 | M | 2 Digit ISO Country Code, per ISO 3166 Standard. |
<destinationPostCode> | C–10 | C | |