Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

Make sure all this actions are performant and responses are provided within millisecondsin less than 3 seconds for p99. Long response times will translate into long loading times for guests.

...

The POS must return the price and availability for each item in the order, the total price and any errors using the Price Webhook Callback endpoint.

If there’s any errors that prevented a successful pricing, they should be reported using the partnerErrors field. Errors that prevent successful pricing can be related to menu items availability, store availability, POS technical issue, etc.

These pricing actions will be triggered trigger every time guests access the cart page.

...

When an order is placed, it needs to be acknowledge by and registered in the POS. Every time an order is placed we trigger the Commit Order webhook. The payload of the webhook includes the order id, payment details, the final total order price and customer details, customer details and “firing instructions".

Note that the Commit Order webhook payload does not include all order details because the POS has received all relevant information about the order previously via the pricing webhook (service mode, order number, etc.). You can also fetch all order information from the GET Order endpoint, at any time.

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 .

If there’s any errors that prevented a successful commit, they should be reported using the errors partnerErrors 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.

...

All order events are broadcasted through our order event webhook.

Order statuses must move forward in the lifecycle shown on the diagram below. Status updates that do not move the order status forward will be disregarded.

...

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 fireOrderInSeconds scheduled time sent in the commit is reached.

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.[ ]

Canceled status can trigger in 3 different cases:

  • For pick up orders, guest selects the Cancel Order option. This option is only available in some markets.

  • Order is canceled by the delivery provider in their Driver Management Portal.

  • Restaurant team member cancels order in the POS (when possible). In that case the POS must inform us that the order is canceled via the Order Event endpoint.

ERROR

Error with the order. Customer should will be notified and refunded when applicable.

When the POS notifies us there’s been an error in the Price Webhook Callback endpoint or the Commit Webhook callback endpoint.

...

.

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).

...