...
The POS must respond to the webhook request by using the Commit Webhook callback endpoint. In this callback, the POS should use the status COMMITTED and indicate if .
If there’s any errors that prevented a successful commit, they should be reported using the errors field. , and you should use the status ERROR instead. Errors that prevent a successful commit can be related to menu items availability, store availability, POS technical issue, etc. If the order has been committed successfully, no errors should be sent.
Committing and order does not mean that the order should be prepared immediately. In the Commit Order webhook payload we include the fireOrderInSeconds field which indicates when order should be sent (or 'fired') to the kitchen for preparation.
...
The fire webhook can be triggered for any order that hasn’t been fired yet, regardless of the value of fireOrderInSeconds in the commit webhook payload. This means that the fire webhook can be triggered both when fireOrderInSeconds is null or higher than 0.
| Info |
|---|
The |
...
fire request takes precedence over the |
The POS must respond to the webhook by using the the Fire Webhook Callback endpoint. In this callback, the POS should use the status PREPARING and indicate if .
If there’s any errors that prevented prevent a successful commit using the errors field. If the order has been committed successfully, no errors should be sentfiring, the status should instead be ERROR and the errors must be included in the errors field.
Order event webhook and endpoint
The POS must provide order status updates as the order advances through its lifecycle using the Order Event endpoint.
You will notice that some of these statuses are already provided as part of the API actions explained above:
...
During the commit action, the status COMMITTED is passed to our API. It’s not required to send that status again via the Order Event endpoint.
...
All order events are broadcasted through our order event webhook.
These are the order lifecycle statuses:
Status | Description | When does it trigger? |
|---|---|---|
CREATED | Order has been created. | When guests access the cart page. |
PRICED | Order has been priced. The POS has provided price information for the order. | When the POS returns price info via the Price Webhook Callback endpoint. |
COMMITTED | Order has been committed. The POS has accepted the order. | When the POS confirms the commit via the Commit Webhook callback endpoint. |
PREPARING | Order is being prepared in the restaurant | When the POS responds to the Fire Webhook Callback endpoint, or the |
PREPARED | Order has been prepared and is ready for pickup or delivery. | When the POS informs that the order is ready via the Order Event endpoint. |
DONE | Order is done. This is the final state for a successful order. | [ ] |
CANCELED | Order has been cancelled. | |
ERROR | Error with the order. Customer should be notified and refunded. |
...
When the POS notifies us there’s been an error in the Price Webhook Callback endpoint or the |
You can use the order event webhook to validate that the statuses actions you are providing performing are being reflected correctly in our system, and that the order is moving through statuses correctlyits lifecycle statuses.
For orders that originate in RBI’s platform, you will notice that most of these statuses are generated by our platform automatically as the order moves through the API actions described in the previous sections (pricing, committing, firing).