Order Type Prep Times & Throttling
Answered
We are researching retrieving order type prep time & throttling values from Toast for use on our platform. A few questions popped up when reviewing your API guides.
---
Do webhooks exist that notify integrated partners when changes are made to the following settings? If not, how are other integrated partners handling getting this information when staff adjusts these settings at a location?
- restaurant 'openTime' and 'closeTime'
- 'deliveryPrepTime'
- 'takeoutPrepTime'
- 'deliveryThrottlingTime'
- 'takeoutThrottlingTime'
--
With the '<orderType>TimeAfterOpen' field, the documentation mentions that this is the amount of time before or after a location opens that it starts accepting orders. Do you have an example of what data returned in this field looks like? How will we know if they start accepting orders before or after a location’s open time?
--
When placing a ‘delivery’ or 'takeout' order, will Toast upon receipt apply order prep + throttling times to it and return the ready time in the order response? Or is the expectation that the integrated partner will need to calculate the order ready time on their side and pass that in when creating the order?
-
Hi Bob,
We do not currently have a webhook to notify integration partners when changes are made to ordering schedules. However, this is on our roadmap and should be available this year. Other integration partners handle retrieving this information by sending periodic GET requests to the Restaurants API and the Order Management API. This guide on calculating order wait times is a helpful reference when using the Restaurants API.
The Restaurants API provides configuration information about a restaurant, including:
- 'openTime' and 'closeTime'
- 'deliveryPrepTime'
- 'takeoutPrepTime'
The /orderingSchedule endpoint of the Order Management API is used to retrieve a restaurant location’s online ordering schedule. This is a more precise way to retrieve takeout and delivery specific schedules, instead of relying only on the Restaurants API. This endpoint is currently in beta, but we are happy to grant you access. We’ve gone ahead and added the digital_schedules:read scope to your sandbox credentials to test. Once you are done with your testing, reach out and we can set this up for you in prod. To retrieve delivery and takeout hours, send a GET request to: https://[toast-api-hostname]/ordermgmt-config/v1/published/orderingSchedule
Our documentation references '<behavior>TimeAfterOpen' and '<behavior>ThrottlingTime' fields, however your integration should not use these. They are no longer available in Toast Web.
The Toast platform calculates expected order prep time and returns this information in the 'requiredPrepTime' field in the Orders API response JSON. If your integration does any of your own calculations to determine prep time, it should be submitted in the 'requiredPrepTime' field with the order. As a best practice, we also suggest displaying this prep time information to the restaurant guest, whether calculated by your integration or by the Toast platform.
Please let us know if you have any follow up questions!
Thanks,
Ann0 -
Hi Ann,
Thank you for your response. Our team did have a few follow-up questions for you:
Order Prep Times + Throttling Times
You mentioned that '<behavior>TimeAfterOpen' and '<behavior>ThrottlingTime' fields should not be used.
If a restaurant is setting throttling times at a location for delivery and pickup orders, are the throttling times returned as part of 'deliveryPrepTime' and 'takeoutPrepTime' calculations or are they returned somewhere else?
We are looking to display Toast pickup and delivery wait times (aka prep time + throttling) per location on our platform to set the right fulfillment expectations with guests before they build/place their order.
<behavior>TimeBeforeClose
Will the <behavior>TimeBeforeClose be removed from Toast web or can these fields be used by an integration?
New /orderingSchedule endoing in the Order Management API
- Can you please provide an example of what the response body looks like to a request?
- What actions performed by a restaurant on the POS does the new API resource take into account?
- Does the new route require any changes to a restaurant's operational processes to take advantage of it or does the resource rely on existing settings they may already be using?
Thank you again for your assistance,
~ bob
0 -
Hi Bob,
After some additional research, I found the throttling times fields do still exist in Toast web and on the POS. Sorry for missing that in the previous post. Throttling times are not automatically calculated into the prep time values displayed via the Restaurant API.
To determine when a future order will be ready, look at the promisedDate in the Order JSON. If an order is submitted with a promisedDate, it fires to the kitchen at (promisedDate-requiredPrepTime). ASAP orders are fired to the kitchen as soon as they are received and their promisedDate is null. ASAP orders are ready at (createdDate+requiredPrepTime).
Use the /orderingSchedule endpoint of the Order Management API instead of the ‘<behavior>TimeAfterOpen’ and ‘<behavior>TimeBeforeClose’ and fields in the Restaurants API. This endpoint replaces that information by providing the Online Ordering schedules set in Toast web. This Toast Central article outlines how restaurants set online ordering hours. These hours will automatically match existing restaurant hours, but restaurants are encouraged to modify them to reflect when they will take online orders.
Example response body from the /orderingSchedule endpoint can be found in our developer guide.
Thanks!
0 -
Thank you again for providing this information Ann!
~ bob
0
Please sign in to leave a comment.
Comments
4 comments