Webhooks
Requires an Integrations license.
A webhook (also called a callback or push API) is used to provide other applications with real-time information. In CXT Software’s context, webhooks are used by the Operations App to provide integration/trading partners or other third-party applications with real-time data based on status events such as picked up or delivered. Typical APIs require third-parties to regularly poll your system for updates while webhooks save time and resources by making the constant polling unnecessary. The callbacks will be sent to the defined URL via an HTTP POST request.
The webhook functionality is available in a basic or advanced option.
Basic Webhook
A basic webhook sends a pre-determined set of basic JSON formatted data from your system to a third-party system via HTTP POST when a status event occurs (such as picked up or delivered). For example, this could be sending an update from your system to your trading partner when you’ve completed a pickup or delivery for one of their orders.
Because basic webhooks are used to notify trading partners that an action has been taken on an order, the content of the message may not provide significant detail. Trading partners will likely prefer to request a full order update from the API as a follow up call for more information.
Examples
For primary order status events (such as confirmed, at pickup, picked up, delivered, etc.), basic data includes the order ID, event type, and any date/time stamps for that job (if captured by the driver at the time of transmission)
For additional order status events (such as canceled, invoiced, driver assigned, status code added, etc.), basic data includes the order ID, event type, and date/timestamps for the event
For address change status events, basic data includes the order ID, date/timestamp of the event, and address information
For primary route stop status events (such as arrived, completed, signature, etc.), basic data includes the route stop ID, event type, and any date/time stamps for that job (if captured by the driver at the time of transmission)
For additional route stop status events (such as consolidated, deactivated, status code added, etc.), basic data includes the route stop ID, event type, and date/timestamp of the event
Setup & Configuration
The following setup and configurations are done in the Operations App.
X Stream Definition
The X Stream definition will automate the processing of the webhooks, using message formats and customer status events.
Create an X Stream definition with the following settings.
Configuration Type: WBOUTBOUND
Export Type: Plugin - Plugin
Plugin Export Type: Webhooks
Key Value definition
URL - Enter the URL to send the webhook messages to
See X Stream Definitions.
URL is the only key value pair required. For advanced webhooks see Optional Settings below for more setup options.
Please contact Technical Support for more information or questions.
Setting | Description |
---|---|
Method | Web method to be used (e.g. POST, PUT, PATCH, etc..) (defaults to POST) |
ContentType | Content type to be used can be application/XML or application/json (defaults to application/XML) |
BodyType | Data type sent back from the stored procedure (NOTE: THIS MUST BE SET TO EITHER JSON OR XML depending on what the stored procedure is returning) |
HeaderTag | Tag used to denote header keys (defaults to header_) (NOTE: See below for more information) |
DateTimeFormatting | Option that the time values are based on.
|
BatchProcessStoredProcedure | Stored procedure used during batch processing (defaults to spWebHooksBatch) |
BatchXsltAttachmentID | XSLT attachment ID used during batch processing (NOTE: See below for more information) |
QueueStoredProcedure | Stored procedure used during queue processing (defaults to spWebHooksQueue) |
StoredProcedureDataType | Data type returned by stored procedure (either XML or json) (defaults to XML) |
ThrowExceptionOnWebCallFail | True/false to enable disable throwing an exception if a web call does not return OK/200 (defaults to false) |
RestClientTag | Tag used to denote rest client keys (defaults to restclient_) (NOTE: See below for more information) |
SignatureEncoding | Signature format to export (e.g. NONE, BMP, GIF, PNG, JPG, SVG, TIF) (defaults to NONE) |
SignatureElement | Data node that contains signature (NOTE: This is post XSLT processing) |
Authentication Tags | |
AuthUrl | Authentication URL |
AuthMethod | Authentication web method to be used (e.g. POST, PUT, PATCH, etc..) (defaults to POST) |
AuthContentType | Authentication content type to be used (defaults to application/XML) |
AuthBody | Authentication body |
AuthUsername | Authentication user name. (Sent as part of Authorization Basic header) |
AuthPassword | Authentication password. (Sent as part of Authorization Basic header) |
AuthAccessTokenNode | Authentication node that returns the token (defaults to token) |
AuthExpiresInNode | Authentication node the returns the expires in value (can now be empty if authentication does not return an expires in value - defaults to 0 if not returned) |
AuthorizationHeaderToken | what is sent back with authorized calls (defaults to Bearer). This is what is sent in the header of authorized calls (e.g. "Authorization", "Bearer 239203239203kdlad03") |
RetryMax | Number of retry attempts (defaults to 0) -- 0 is disabled |
RetryDelay | Number of seconds to wait between retries (defaults to 0) -- 0 is disabled |
RetryDelta | Number of seconds to increase the delay for each retry (defaults to 0) -- 0 is disabled |
Header Tags | |
HeaderTag | String that will denote header values (defaults to header_) Keys that start with the HeaderTag will be passed as header parameters (e.g. header_apikey - the associated value will be passed as "apikey" request header parameter) |
Restclient Tags | |
RestClientTag | String that will denote rest client parameter (defaults to restclient_) Keys that start with the RestClientTag will be used to configure the rest client. (e.g. restclient_timeout - the associated value will be set used to set the timeout value in the rest client) This is a list of the rest client configuration settings that can be configured:
|
Message Formats
Message formats are used for basic updates to send the message that the webhook was triggered. Advanced webhooks may require additional setup or configuration.
Create the appropriate message formats for the order or route stop that will be used with webhooks. For example, if you want to send picked up and delivered information, create two message formats (one for Order Picked Up and one for Order Delivered).
Check the Execute SQL Statement checkbox in the Advanced tab.
Paste the appropriate SQL commands into the Advanced tab of the message format.
Example command for a Order Picked Up message format:
EXEC spWebHooksProcessEvent @ORDERID=[OrderID], @TYPE='ONDEMAND', @EVENT='PICKEDUP'Example command for a Order Delivered message format:
EXEC spWebHooksProcessEvent @ORDERID=[OrderID], @TYPE='ONDEMAND', @EVENT='DELIVERED'
See Message Formats (Classic Operations App) or Message Formats.
Customer Status Events
Status events on the customer record are what will send the message format when the webhook is triggered.
In the customer record, go to the Contacts tab.
In the Alerts section, select the Status Event and the corresponding Message Format you created.
Repeat step 2 as needed.
Save the customer record.
See Customers - New/Edit Customer.
Advanced Webhook
An advanced webhook is similar to a basic webhook, but with customization options for the information included in when a status event occurs. If the pre-determined set of details from the basic webhook does not provide the trading partner with the information they need (or they are not able to make a follow up API call to get more info, and prefer to accept web posts) the details sent via the webhook can be expanded using the advanced webhooks to provide more information in real-time. Any configuration of custom advanced webhooks will require Integration Services assistance to match a requested format.
Customizable JSON/XML payload to provide selected order or route stop information.
Sends information in JSON or XML format
All order and/or route stop fields are available to be sent over (see Optional Settings below)
Triggered by Status Events
GPS updates can be set up to send on a recurring schedule