Use Webhooks

Now that you know how webhooks work, you can now manage Webhooks through the webhooks API.


To properly configure a webhook, you need one webhook URL with the following:

  • Available on the public Internet
  • Valid SSL certificate and served as https
  • Supports POST calls from Shipwell
  • Attaches to the software or server from which you parse or transform Shipwell data

We recommend that you create one webhook per event type. Event types can have different versions. Creating one webhook per maintenance of your webhook easier.

Security & Verification

  • SSL Certificates and HTTPS
    • Ensure that your webhook URLs have a valid SSL certificate and begin with https:// as the URL scheme.
  • IP Addresses and Verifying Webhook Requests/Payloads

Add the webhook URL

After you've configured your server to receive Shipwell Post calls, post the Webhook URL using the Post webhook endpoint. You'll need at least the following information in the request body:

  • url: Your secure webhook https URL with a valid SSL certificate
  • enabled_events: A list of the Shipwell events for which you want the webhook to receive
  • error_contact_email: An email address to contact if your webhook fails to receive every payload 5 times
  • event_version: The version of the event type configured to your webhook. Refer to Types of events to see the event version. You might have to POST the webhook URL twice should you want to the same webhook URL to listen for events with different versions. We recommend using one event type per webhook.
If you choose not to indicate an event version, the event payload will default to the latest version.In this example, curl is used to post a test webhook URL to the sandbox environment ( to listen for the shipment.created and shipment.updated events:
For production usage, remember to replace with the production environment of
curl --request POST \
  --url \
  --header 'accept: application/json' \
  --header 'content-type: application/json' \
  --data '{"enabled_events":["shipment.created","shipment.updated"]
,"event_version":1, "error_contact_email":"",
import requests

base_path = ""
host_path = ""
target_url = (
    + host_path
    + base_path
    + "/webhooks/"

headers = {
    "Authorization": "YOUR_AUTHORIZATION_HEADER",
    "Content-Type": "application/json",

payload = {
    'enabled_events': [
    'status': 'ENABLED',
    'include_updated_object': False,
    'event_version': 1,
    'error_contact_email': '',
    'url': '',

response =, headers=headers, json=payload)
data = response.json()

Test your webhook

When configuring a webhook through the sandbox environment in Shipwell, you can test your webhook to make sure it receives event payloads. Using the example from "Add the webhook URL".:

Trigger an event

Trigger one of the events configured with your webhook either through the Shipwell UI or through the Shipwell API. For example, if you configured a webhook to listen for shipment.created, create a shipment.

Verify payload

Upon creation of the event payload, your webhook receives two additional custom headers used to verify that the payload was sent to the webhook URL:

  • X-Shipwell-Signature - a unique signature generated from the body, X-Shipwell-Timestamp and the Webhook secret
  • X-Shipwell-Timestamp - an ISO-8601 timestamp indicating when the signature was generated, used for signature verification

These 2 headers can be used to verify that you are receiving payloads from Shipwell.

To verify a payload:

  1. Generate a signature_payload by concatenating:
    1. X-Shipwell-Timestamp header
    2. A semicolon, ;
    3. The JSON payload you received (use the raw request body without formatting)
  2. Using the signature_payload, generate a SHA-256 signature using the Webhook's secret as the key.
  3. The computed signature should match the X-Shipwell-Signature. Don't worry, sandbox data is not real data for customers, bills, invoices, or shipments or any other objects in your account. If your endpoint is working successfully, you’ll see the webhook get executed on your server. Additionally, you can call the Events API and look for the specific event you received.

The following is a flask example of verifying a webhook signature:

import hashlib
import hmac
from flask import Flask, request, abort

app = Flask(__name__)
webhook_secret = ... # the Webhook secret is generated and returned when creating a Webhook

@app.route('/webhook', methods=['POST'])
def webhook():
    if request.method == 'POST':
        received_signature = request.headers.get('X-Shipwell-Signature')
        timestamp = request.headers.get('X-Shipwell-Timestamp')
        if not received_signature and not timestamp:

        signature_payload = timestamp + ";" + request.get_data() # need the raw String to compute the signature
        signature =,

        if signature != received_signature:

        print(f'Received data from Shipwell! {request.json}')
        # This must return in less than 10 seconds
        return '', 200


if __name__ == '__main__':

We recommend using a cryptographically secure signing key when configuring your endpoints as well as having all endpoints verify the signature matches the payload to ensure the request is authentically from Shipwell.

Example payload

All events received by your webhook use a custom JSON payload depending on the event type, according to the OpenAPI specification, the following is an example of a generalized event payload:

  "id": "545b40eb-1adf-43a2-9159-64190400900b",
  "occurred_at": "2020-04-20",
  "source": {
    "user_id": "fdc6a67b-0533-485c-8e96-ee98d703b8bb",
    "company_id": "f75099e9-a057-46a5-9fc6-490332a110f6",
    "request_id": "919386f2-c8cf-4670-a1ee-1a5e09b6e1f9",
    "publishing_system": "backend",
    "environment": "sandbox"
  "event_name": "shipment.created",
  "details": {
    ... // details varies by event

The Event object schema uses the OpenAPI 3 for the event body:

openapi: 3.0.2
  version: "1.0.0"
  title: Webhook payload

      type: object
        - publishing_system
      description: >-
        Object containing data associated with the source of the event.
          type: string
          nullable: true
          description: "The user that originated the event, if applicable."
          type: string
          nullable: true
          description: "The company that originated the event, if applicable."
          type: string
          nullable: true
          description: If the event came from an API request, the ID of that request is null unless system generated.
          type: string
          description: "The system name where the event originated"
          example: "shipwell.rating"

      type: object
      description: |
        What the external endpoint (specified by the Webhook `url`) receives as a `POST` body.
      readOnly: true
        - id
        - occurred_at
        - source
        - event_name
        - details
          type: string
          description: Unique ID of the event.
          type: string
          format: 'date-time'
          description: When the event occurred.
            - $ref: '#/components/schemas/Source'
            - type: object
                - environment
                  type: string
                  description: >-
                    The environment from which the event was generated. Useful in scenarios where the same hook subscribes to events in multiple environments.
                  enum: [dev, sandbox, prod]
          type: string
          description: Which particular event is being received. This will always be a subset of what was specified in enabled_events
          type: object
          description: The event payload that was subscribed to. The contents differ both on the event name as well as the event_version that was subscribed to
          type: object
          description: If the original Webhook `include_updated_object` was true, this becomes the new object. Otherwise the object does not appear.

Respond to webhook events

Your endpoint must return a 2xx HTTP status code within 10 seconds when it has sucessfully received an event. This might mean you need to run business logic as a background job if it cannot be completed within the 10 second response.

If your endpoint does not return any successful responses to Shipwell events we may automatically disable the webhook. You will receive a notification to the configured error_contact_email if this occurs. To re-enable the webhook, send a PATCH request to update the status field to ENABLED. See the docs for more information

Event delivery

Timeouts and retries

When a webhook is triggered, Shipwell queues the event and webhook to be published. If the webhook is unsuccessful in delivering the event (the remote server was unreachable, returned a non-2xx HTTP response, or the took longer than 10s to respond), the webhook handler will attempt to deliver the payload to the webhook again after a 20 min wait. We'll try to deliver the webhook up to 5 times, doubling the delay between each attempt. If the webhook handler gives up, Shipwell will send an automatic email to the email address submitted with the webhook configuration.

Shipwell will automatically follow all redirects returned by the server; however, more than 30 redirections are considered a failure. Additionally, the status code found to determine if the webhook request succeeded or not is the last one received in the chain of redirections. Shipwell ignores any other information returned in the request headers or request body.

The majority of webhook issues result in 4xx and 5xx HTTP status codes.

  • 4xx indicates Shipwell was able to contact your server, but the endpoint was not valid. Double-check that the endpoint URL is correct and ready to receive POST requests.
  • 5xx usually indicates an exception on your server.

Event ordering

Shipwell does not guarantee the order of the delivery of webhook events, i.e. events may be delivered in a different order than the events or data was generated. For example, creating an purchase order then a shipment may generate the following events where the shipment details arrive before the purchase order details:
  • shipment.created
  • purchase_order.created
As a best practice, your endpoint should be able to handle receiving the events out of order. You may use the API to retrieve any missing data or objects for your use case (e.g. if you receive a shipment before an purchase order and your workflow requires the purchase order then you may retrieve the purchase order, customer, shipment, etc. in API calls using information from the shipment if you happen to receive the shipment first).

Handling duplicate events

Shipwell does not guarantee exactly once event delivery. This is common for event delivery systems that support scale and speed and there are common ways to handle if you receive a duplicate event.

  • Ensure that your event processing is idempotent
    • You may log or save events processed, after creation/save of an item look that up in a database/cache/data store, etc., and then do not process those events
    • You may utilize the event id, event name, etc. when determining if you have already logged/processed/recorded an event in your system

Go live

Once you've verified your webhook URL is receiving, acknowledging, and handling events correctly, go through the configuration step again to configure a webhook URL for your production integration. If you're using the same webhook URL for both sandbox and production modes, the X-Shipwell-Signature is unique to each environment. Make sure to add the new signature to your endpoint code if you're checking webhook signatures.
Copyright © Shipwell 2024. All right reserved.