Empowering Restaurants through Integration

Follow

Menu Refresh Webhook

This webhook is used to automate the process of refreshing menus for menu updates and item 86ing.

This webhook requires the Show Menu endpoint for each location within the List Locations endpoint.

Grubhub also requires the Get Unavailable Menu Components endpoint to be used for item 86ing (removal of a menu item or option).

Step 1: Call the Menu Refresh Endpoint

The menu refresh endpoint requires an internal Grubhub merchant ID within the URL and a merchant token for the authorization. Both fields can be generated and provided by a Grubhub engineer for both production and sandbox environments.

Request Endpoints

Production:
POST https://api.thelevelup.com/v15/merchants/:merchant_id/refresh_menus
Sandbox:
POST https://api.sandbox-levelup.com/v15/merchants/:merchant_id/refresh_menus

Example Response Body

{
"location_ids": [
11111
]
}

 

Example CURL Command

curl -X POST \
https://api.thelevelup.com/v15/merchants/123456/refresh_menus \
-H 'Accept: application/json' \
-H 'Authorization: token merchant=XXXXX-XXXXX-XXXXX-XXXXXX-XXXXXX' \
-H 'Content-Type: application/json' \
-H 'cache-control: no-cache' \
-d '{
"location_ids": [
11111
]
}'

 

Example Response Schema

{
"type": "object",
"properties": {
"location_ids": {
"type": "array",
"items": {
"type": "integer",
"description": "The provider ID of the location that needs to be refreshed"
}
}
},
"required": [
"location_ids"
]
}

 

Step 2: Return the Unavailable Items

When Grubhub receives the POST request to the refresh menus endpoint, we kick off the menu refresh process for the location IDs provided in the payload of the webhook.
The menu refresh process on our end has two steps. Let’s use Location 11111 from the above
example to illustrate this process:
  1. Grubhub calls the Show Menu endpoint to pull the latest version of the menu for this location:

    GET /locations/11111/menu

    If you are removing an item or option, the Show Menu endpoint should return an unchanged menu, including items that have been removed.

  2. Grubhub then calls the Get Unavailable Menu Components endpoint to get the latest data on unavailable items for this location:

    GET /locations/11111/unavailable_menu_components

Let's say this location has only one item on the 86'ed list, as seen below:

{
"provider_id": "11111",
"localTimeStamp": null,
"items": [
{
"universal_id": "2421",
"name": "Burger",
"date": "2019-02-19T10:00:00.000"
}
]
"options": [
{
"universal_id": "2425",
"name": "Ranch Dressing",
"date": "2019-02-19T10:00:00.000"
}
]
}

 

Grubhub then drops "Burger" item and "Ranch Dressing" option from the menu and pushes the final menu to Grubhub Marketplace.

The steps of the menu refresh process occur each time we do a menu refresh. We expect the brand to maintain the list of unavailable items dynamically throughout the day. If the “Burger” above was made unavailable at 10am but is back in stock at Noon, we would expect the brand to remove it from the response of the /unavailable_menu_components so we can add it back to the menu as part of the next menu refresh.