Dates with coverage on address

Purpose and use of service

The API provides a list of future distribution dates that have delivery or pickup coverage for of a product on the specified address. The product are determined from the freight product (freightProductId). The remaining fields along with the customer name field will be used to lookup the address in the carrier system.

The coverage check is based on the coverage available from the carrier. We continuously receive updated information from the carrier, and therefore the delivery option result may vary with time
To determine coverage we also look at previous shipment to similar addresses and consumers, this help correct misspellings and find coverage.

Integration tips

We recommend to always include all information you have available, and use the same information in other relevant APIs to ensure the results are consistent
Specify household number where possible, e.g. H0201, in order for the system to match of the address as exact as possible

Setup

	Example	Description
Username (see Authentication section)	wsfoobar	A valid username.
Password (see Authentication section)	a-very-very-long-password	A password matching given username.
shopId	12345	The coverage check is made with respect to a given shop.
freightProductId	55	An identifier for a valid freight product.

The user is a web service user
The user has access to the shop where registering the parcel
The shop has access to the specified freight product

Environments / endpoints

TEST POST	https://staging-ws.di.no/ws/json/addressCheck/single/v-1/dates?limit=14
PRODUCTION POST	https://ws.di.no/ws/json/addressCheck/single/v-1/dates?limit=14

Making a request

Clients using this API should not fail if new optional fields are added to the API. If a new field is added to the request or response on a later stage, existing clients should handle this in a way such as they just ignore the field.

Request header

Field	Value
Content-Type	application/json
Authorization	$SECRET_WS_TOKEN - jwt token from authentication

Request body

Field	Description	Example	Data type
shopId	The identifier of the shop that makes the request	23	Integer
freightProductId	The freight product that we want check the coverage of	12	Integer
customerName	Customer name	Ola Norrman	String
countryCode	Two letter country code of the address	NO	String
postalName	City name of the address	Oslo	String
zipCode	Zip code of the address	0155	String
address	Street name of the address	Akersgata 55A H0212	String
co	Care of address of the address	Kari Norrman	String

Field	Value
Content-Type	application/json
Authorization	$SECRET_WS_TOKEN - jwt token from authentication

Curl request example

Example

curl --location 'https://staging-ws.di.no/ws/json/addressCheck/single/v-1/dates?limit=14' \
--header 'Authorization: Bearer $SECRET_WS_TOKEN' \
--header 'Content-Type: application/json' \
--data '{ 
"shopId": "33",
"freightProductId": "10",
"customerName": "Ola Norrman",
"countryCode" : "NO",
"postalName" : "SEM",
"zipCode": "3171",
"address": "GAMLE RAMNESVEI 38",
"co" : "Kari Norrman"
}'

Response

The endpoint replies with a response object in JSON format, containing the following data

Field	Description	Example	Data type
dates	A list of dates that are supported	[ "2024-04-16", "2024-04-17"]	Array of strings

Example response

Example

{
    "dates": [
        "2024-04-16",
        "2024-04-17",
        "2024-04-18",
        "2024-04-19",
        "2024-04-20",
        "2024-04-22",
        "2024-04-23",
        "2024-04-24",
        "2024-04-25",
        "2024-04-26",
        "2024-04-27",
        "2024-04-29"
    ]
}

Error handling

API requests that result in errors will return an appropriate HTTP status code to help you identify the type of error. You can use the table below to understand what each code means. og search online with the HTTP status code. The HTTP error keys used are based on the standard, and therefore available online (Tips to search “HTTP code XXX”)

In addition to HTTP status there may be more details in the errorKey field. Error Keys can be added at a later stage, clients should handle this as well as an empty value for errorKey.

HTTP Status code	Text	Description
400	Client or Validation Error	The request body/query string is not in the correct format.
401	Authentication Failure	Indicates that the Authorization header is either missing or incorrect. You can learn more about the Authorization header here.
403	Access denied	This indicates that the agent whose credentials were used in making this request was not authorized to perform this API call. It could be that you do not have access to the shop or transportsolution you provided in your request. If you believe this is a mistake, please reach out to your contact so it can be rectified.
405	Method not allowed	This API request used the wrong HTTP verb/method. For example a PUT request will result in this error.
4xx	Client error	Generally receiving an error code that starts with 4 indicates that the client needs to change something.
500	Unexpected Server Error	Oops! This may indicates an error on our side. Please try again, if the error continues notify your contact person

Error Keys

List of error keys

error key	status code
required.shop.id	400
wrong.shop.id	400
wrong.freight.product.id	400
no.access.shop.id	403
internal.error	500

Error response

In addition to the HTTP status code, most errors will also return a response body that contains more information to help you debug the error. A sample error response is shown below. The format of the error response body is explained after the example. New error keys may occur, you should handle this according to the HTTP status code.

Sample error

Example

{
    "statusCode": 401,
    "errorKey": "authentication.missing",
    "errorMap": {}
}

Field	Description
statusCode	The HTTP code associated with this error.
errorKey	A machine parseable error code, this may be empty and new errorKeys can be added at a later stage
errorMap	Additional details pertaining to the error.