Webhook use-cases

Table of contents

• Introduction
• Notifying a customer when their order has shipped
• Integrating with a shipping platform
• Subscribing to article data

Introduction

When Ongoing WMS triggers a webhook, a JSON payload is sent to the receiver. The payload contains information about the event which triggered the webhook. The information in the payload is usually quite minimal. For instance, if you have set up webhook which will be triggered whenever an order is picked, the payload will contain the order number and order ID. If you require more information about the order (such as the customer's email address) to be able to properly process the webhook, you can make an additional API call back to Ongoing WMS where you fetch the order data.

On a high level, processing a webhook always follows the same pattern:

1. Ongoing WMS triggers webhook.
2. A JSON payload is delivered to the receiver.
3. If necessary, the receiver will make one or more additional API calls back to Ongoing WMS to fetch more information.
4. The receiver processes the webhook.

In this document, we give examples of some ways of using webhooks.

Notifying a customer when their order has shipped

1. Create a webhook which triggers every time an order reaches the status Sent.
2. When the webhook is triggered, your webhook receiver will receive an order ID.
3. Fetch the order from the Ongoing WMS API (if you are using the SOAP API, use GetOrdersByQuery, and if you are using the REST API, make a GET request to /api/v1/orders/{orderId}).
4. The customer's email address will be available in the fetched order data.
5. Send an email to the customer.

Integrating with a shipping platform

Ongoing WMS provides integrations with many shipping platforms, but some customers choose to write their own integration. You can use the automation API to create an integration between Ongoing WMS and a shipping platform like this:

1. Create an automation webhook which triggers every time an order reaches the status Sent.
2. When the webhook is triggered, your webhook receiver will receive an order ID.
3. Your webhook process can use the API call GetOrdersByQuery to retrieve the order from Ongoing WMS.
4. Since the webhook will be triggered for all orders, it may be necessary for your webhook process to decide whether to proceed with the order. As an example, your webhook process can use the Transporter field to determine if the order has the correct transporter.
5. If your webhook process should not proceed, then you can simply stop processing.
6. Otherwise, your webhook process makes the necessary transport bookings, by making API calls to some other system.
7. Once the transport booking has been made, your webhook process can use the following API calls to send back information to Ongoing WMS:
   • UploadOrderFile - can be used to attach one or more PDFs to an order.
   • UpdateOrder - can be used to add a tracking link to an order.
   • CreatePrintJob - can be used to print the above-mentioned PDFs.
   • ReportOrderTransportStatusEvent - can be used to inform the warehouse of various events (such as "the order has been delivered to the end customer").

Subscribing to article data

If you keep the master data for your articles in Ongoing WMS, then you may wish to sync some other system to this data, so that whenever the data changes in Ongoing WMS, this will be reflected in the other system. This can be accomplished like so:

1. Set up three webhooks: one for when articles are created, one for when articles are deleted, and one for when articles updated.
2. Whenever the creation and deletion webhooks are triggered, simply create or delete the corresponding article in your system.
3. Whenever the update webhook is triggered, make an additional API call to Ongoing WMS to fetch the article data.
4. Compare the data in the API response to the data which you have in your own system, and update it as needed.