Notifications Overview

The OMS Notification System provides order event notifications throughout the fulfillment process. Notification data is compiled automatically as the order progresses through fulfillment stages, and then sent to a JSON endpoint set up by the client. Note that these notifications are not emails sent to the consumer, but sets of data for fulfillers and clients to track the progress of the order. This system is initially configured by Kibo Professional Services.

The Notifications system is integrated with both OMS APIs and interfaces. There are not separate notification types for events that happen in the interface and the APIs; rather, they are triggered by any appropriate event regardless of where it happens. However, some notification variants may only apply to a specific fulfillment type and thus are dependent on what the interface supports. For example, when a client is using the retailer interface that doesn’t allow In-Store Pick Up fulfillment but does allow Ship to Store (Automated), then STSA-specific notifications will be triggered when a retailer puts an order through fulfillment.

This overview lists important things to remember about JSON endpoints, topic buckets, and the default structure of OMS notifications. Read those tips before delving into the more detailed information and examples linked in the Notification Topics table below.

Important Notes About Endpoint Configuration

OMS expects a 200 OK success response to be returned from the JSON endpoint within 45 seconds of sending the notification. If no success response is received during that time or if an HTTP status error message is received, the notification will be placed in a queue to be resent every minute or so (the actual timing will vary based on the size of the queue). The notification will continue to be resent until either the success response is received or the notification expires after 14 days.

Due to this process, the JSON endpoint may sometimes receive duplicates of notifications. To avoid saturation with a large number of duplicates, it is recommended to configure the endpoint with duplicate prevention.

Additionally, this means that it is possible for notifications to sometimes be received out of order. For example, if the Ready Order Notification failed and was placed in the retry queue, but the subsequent fulfillment and Package Complete notifications are successfully sent on their first try, then Ready Order may be received last. Thus, it is also advised to configure the endpoint to be capable of receiving out-of-order notifications to avoid any problems that may be caused by expecting notifications in a strict order.

Notification Topics

Notifications are organized by topics, which are buckets of one or more notifications that are all associated with a particular process such as returns or shipments. The following table provides a quick reference to the basic notifications topics that are used in OMS. For more details about the data provided in each notification and examples, click the name of the topic to view that guide.

Topic	Description
Return Event	Return event notifications are sent for the creation, modification, and removal of returns. They will be triggered when a return is created, accepted, declined (or deleted), re-opened, and cleared.
Shipment Assign	This notification indicates that a shipment has been assigned to a fulfillment location.
Payment Transaction Error	This notification is sent after a capture or refund attempt against a transaction has failed 3 times.
Shipment Status	All shipment fulfillment state updates are reported by this notification.
Order Appeasement	This notification indicates that an order appeasement (or goodwill credit) has been initiated.
Order Status	Similar to Shipment Status, this reflects updates in an order’s status (including order creation).
Store Decline	This notification is sent when a store declines a shipment of items.
Order Item Modification	This is sent when the price, quantity, or tax of an order item is edited, or when an order item is canceled.
Order Address Change	This is sent when an order’s billing or shipping address is edited.

Default Structure

Many notifications use the default structure, unless otherwise noted for a particular use case. The fields of this structure are described in the below table.

Field	Type	Description
eventTypeID	string	The name of the transition that prompted the notification.
stateFromCode	integer	The numeric code for the state that the order transitioned from.
stateFromName	string	The name of the state that the order transitioned from.
stateToCode	integer	The numeric code for the state that the order transitioned to.
stateToName	string	The name of the state that the order transitioned to.
orderID	integer	The order ID that was affected by the transition.
shipmentID	integer	The shipment ID that was affected by the transition.
orderItemID	integer	Null by default. This is only used for the cancel_item notification.
parentOrderID	integer	Null except in the case of a Transfer order, it will be the parent In-Store Pickup order’s orderID
data	object	Null by default. The data field is filled in for specific transitions that require more information with the notification.
scope	object	Contains the mfgID and catalogID that the order belongs to.

The below is an example of the default notification structure, illustrating how these parameters might be defined:

{
    "eventTypeID": "ReturnAcceptedByFulfillerForShipper",
    "stateFromCode": 1100,
    "stateFromName": "return_initiated",
    "stateToCode": 1300,
    "stateToName": "return_accepted_by_fulfiller_for_shipper",
    "orderID": 123456,
    "shipmentID": 654321,
    "orderItemID": null,
    "parentOrderID": null,
    "data": null,
    "scope": {
        "mfgID": "1111",
        "catalogID": "0"
    }
}