For an introduction to Shipup webhooks, please read the guide here. This documentation is a reference for the different webhook settings and fields.

Here is the list of webhook event types that you can register:

tracker.newSent when a new tracker is received by Shipup when a new shipping event is retrieved for a tracker
notification.newSent when a notification is generated
feedback.newSent when a feedback is generated

Webhook event format

When an event corresponding to your webhook settings' webhook event type occurs, Shipup will send a JSON formatted webhook event to the endpoint specified in your webhook settings using the following format:

Unique identifier of the webhook event
Object type. Will always be webhook_event for this object
Data of the webhook event. See format below
Has the value true for production data and the value false for test data.
Webhook event POST retry count. This counter starts at 0 and will increase as the webhook fails being sent
Type of webhook. See table above for the different type codes
Time at which the webhook was created. Will not be updated afterwards and will be prior to the time the webhook is actually sent

The data field object of the webhook event will have the following format:

Root object of the webhook event. For example if the webhook_event_type_code field of the webhook event is, the root object will be a tracker
Information about what triggered the webhook event. For example if the webhook_event_type_code field of the webhook event is, the reason will contain the ID of the tracker's new event


It is possible to configure several ways in which the webhook call will be authenticated


Basic HTTP Auth with a username and a password that will be sent encoded with base64 encryption.

usernameUsername for authentication
passwordPassword for authentication

Oauth 2.0 - JWT Bearer Flow

One of the many flows inside the Oauth 2.0 specification. This is compatible with Google IAP.

AudienceThe audience represents the intended recipient of the JWT. It typically refers to the OAuth 2.0 server or the specific resource server that the JWT is intended for. When the JWT is issued, the audience field specifies who the JWT is intended for. For example, if the JWT is meant for accessing a particular API, the audience would be the URL of that API.
Auth URLThe Authorization URL is the endpoint where the client initiates the OAuth 2.0 authorization process by redirecting the user's browser to this URL. It will be used to obtain the JWT Bearer Token.
Client EmailIn some cases, particularly when using OAuth 2.0 with service accounts, a client email may be used to uniquely identify the client application. This email is associated with the client credentials (e.g., client ID and client secret) and may be required for authentication and authorization purposes.
Client IDThe client ID is a public identifier for the client application, typically issued by the OAuth 2.0 server during client registration. It is used by the server to identify the client application making requests. Along with the client secret (if applicable), the client ID is used to authenticate the client application during the OAuth 2.0 flow.
Private KeyThe private key is a part of asymmetric cryptography, which involves a pair of keys: a public key and a private key. These keys are mathematically related in such a way that data encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. In the context of JWT, the private key is used to generate a digital signature for the JWT.

Custom HTTP headers

It is also possible to include custom HTTP headers that will be sent with each Webhook request.


If a custom header regarding authorization is added at the same time as an authentication method, the custom header will be overwritten with the actual authentication.