The purpose for the API is to show available pick-up of or return retailers nearby a specified address.
Content
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Setup
Make sure you have the following information at hand before proceeding.
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 | 1234 | All requests are made with respect to a given shop. |
transportSolutionId | 5 | An identifier for a valid transport solution. The transport solution determines how the booked package will be distributed. |
...
The user is a web service user
The user has access to the web service for coverage check
The user has access to the specified shop
The shop has access to the specified transport solution
Environments
Consider using the TEST-endpoint while developing your system. By doing this you ensure that your test-data will not pollute any potential external systems.
TEST | POST | https://staging-ws.di.no/ws/json/freightcoverage/v-1/servicepoints |
PRODUCTION | POST |
Authentication
This endpoint requires the user to be authenticated. Refer to the documentation here for more information on how to obtain a valid token to use in your request.
Making a request
Request headers
...
Key
...
| Info |
|---|
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 headers
Key | Value example | Comment |
Authorization | Bearer "SECRET_WS_TOKEN" | See authentication on how to obtain a token |
Content-Type | application/json |
Request body
Name | Type | Example | Mandatory | Max Length | Description |
shopId | whole number | 95123 | n/a | The shop this booking is made for. | |
transportSolutionId | whole number | 1 | n/a | A transport solution is a construct that contains multiple freight products. Its purpose is to group what freight products a customer has access to. | |
countryCode | string | NO | 3 | Country code, according to ISO 3166-1. | |
postalName | string | OSLO | 35 | Also known as postalName. | |
zipCode | string | 0155 | 9 | Also known as postal code. | |
streetAddress | string | Storgaten 11A H0202 | 105 | Combined address information with the following format:
| |
coAddress | String | Hansen | 255 | Care of address |
Curl request example
| Code Block |
|---|
curl -X POST \
https://staging-ws.di.no/ws/json/freightcoverage/v-1/servicepoints \
H 'Authorization: Bearer Token' \
H 'Content-Type: application/json' \
d '{
"shopId" : 1,
"transportSolutionId":1,
"streetAddress":"Nedre skøyen vei 18a",
"zipCode":"0276",
"postalName":"oslo",
“countryCode”:”NO”
}' |
Response
Name | Type |
|---|---|
freightProducts | list of |
freightProducts
Name | Type | Example |
|---|---|---|
transporterId | whole number | 3 |
transporterName | String | Carrier AS |
freightProductId | whole number | 4 |
freightName | String | Express delivery |
freightTitle | String | Express home delivery |
freightDescription | String | Delivery on doormat before 07:00 a.m. |
servicePoints | list of |
properties
propertiesservicePoints
Name | Type | Example |
|---|---|---|
servicePointExternalId | whole number | 3345345 |
servicePointName | String | Pick up point store |
openingHours | list of | There may be more than 1 time intervall for each day, this will be shown as two separate objects E.g. Monday 08:00-10:00 and Monday 14:00-18:00 |
visitingAddress | address object | see example below |
deliveryAddress | address object | see example below |
routingCode | String | ERT |
eligibleParcelOutlet | boolean | see example below |
servicePointCoordinates | List of | see example below |
Examples
| Expand | ||
|---|---|---|
| ||
|
| Expand | ||
|---|---|---|
| ||
|
...
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 meanswhat 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 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.
...
| Code Block | ||
|---|---|---|
| ||
{
"statusCode": 401,
"errorKey": "authentication.missing",
"errorMap": {}
} |
Field | Description |
|---|---|
statusCode | The HTTP code associated with this error. |
errorKey | A machine parseable error code. |
errorMap | Additional details pertaining to the error. |
...
Other notes
DI receive Norwegian postal numbers and coordinates from GEODATA (🔗 LINK) - based on this our algorithm calculates closest ServicePoint