The purpose of this API is to registrere register an event to a parcel. An event is information about something happening that has happened the specific parcel, e.g. it can be a status update or information about consumer communications. Events added will be available for all clients entitled to information about that specific parcel (through Parcel Event Log API v1, Parcel Event Log API v2 or Event Log push service), and used by them as they see fit. If you are uncertain of which fields to populate and how the data will be used consult your carrier.
This API enables externals to add events to the track and trace information and affect the status of a parcel. The added event it self does not trigger any logic or changes for the parcel, nor any consumer communication.
If you registrere register an event and also listen to the event push-queue or fetch event information in the event log API you will get the same event you posted from these sources.
...
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
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. |
The user is a web service user
The user has access to the web service “Parcel Registrere Register Event”
The user has access to the shop the parcel (trackingReference) is connected to
Environments / endpoints
TEST
|
| ||||||||
PRODUCTION
|
|
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
| Info |
|---|
|
Do not share personal or sensitive information in this API....
Name | Type | Example | Max Length | Mandatory | Description |
|---|---|---|---|---|---|
trackingReference | string | (00)370724760010119754 | 35 |
| Tracking reference for the item, typically a SSCC gs1 code. |
eventTime | string | 2020-01-31T00:01:00.000+01:00 | n/a |
| Time of the event registered in originating system. Datetime format ISO-8601 : yyyy-MM-ddTHH:mm:ss+HH:mm |
lat | double | 59.911096 | 9 | Â | Latitude for the location of the event |
lon | double | 10.752457 | 9 | Â | Longitude for the location of the event |
locationContext | string | Oslo | 255 | Â | Address or description of the location/ context of the event. This is typically show to the consumer directly so we recommend sharing a general location, e.g. postal name. |
locationContextId | string | 34567 | 10 | Â | Unique identification of the locationContext |
eventType | string | 001 | n/a |
| Identifier for what has happened to the parcel, see list of possible event IDs here (Same IDs as the list of possible events returned in the Event log API and push service). ⚠️ Include the whole number, also leading 0 |
additionalInfo | string | 001 | n/a | Identifier for additional info on what happened, see list of possible additional info IDs here (Same IDs as the list of possible events returned in the Event log API and push service). ⚠️ Include the whole number, also leading 0 | |
comChannelType | string | SMS | n/a |  | Communication channel only used for event types within event group "communication". ComChannelTypes  in use:
|
message | string | 255 | Â | Optional message from the system registering the event |
Response
HTTP Status code | Description |
|---|---|
200 | Event was successfully registered |
Examples
Request
| Code Block |
|---|
{
"trackingReference": "370724762112345678",
"eventTime": "2022-08-04T12:51:00+01:00",
"locationContext": "my postalname",
"eventType": "013",
"message": "Delivered"
} |
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”)
...
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.
...