...
This endpoint is used when the vendor needs the menu content for populating various touchpoints. Some examples of these touchpoints are aggregator platforms (e.g. Uber Eats) or kiosks.
The menu response after calling this endpoint has a flat JSON, which means it doesn't have nested structures. All fields are root level properties, so you can refer to them simply by ID. The below example is a walk-through from menu to modifier.
...
Tenders example
...
Type
...
ID
...
Name
...
Menu
...
Group
...
menu_1
...
Menu
...
Section
...
Group
...
4763b543-2d04-40a6-8b95-d55750ec554a
...
Tenders
...
Picker
...
Group
...
xdgrygmaqSf78Pjdh6UrTF
...
3Pc Tenders Meal
...
picker_pickerAspect
...
Group
...
xdgrygmaqSf78Pjdh6UrTF-76b9c2d3-536e-46bb-a060-f805a63b0063
...
Choose a Size
...
picker_pickerAspectOption
...
Group
...
xdgrygmaqSf78Pjdh6UrTF-medium
...
Large Combo
...
picker_pickerAspect_pickerAspectOption_pickerAspect
...
Group
...
xdgrygmaqSf78Pjdh6UrTF-76b9c2d3-536e-46bb-a060-f805a63b0063-medium-b376ee07-5ba9-464d-a3b0-e79ad3643e2a
...
Choice of Tenders Preparation
...
picker_pickerAspectOption_pickerAspectOption2
...
Group
...
xdgrygmaqSf78Pjdh6UrTF-medium-spicy
...
Spicy
...
combo
...
Combo
...
00cc6fc6-5ce7-4361-aa95-9d6d726b5bbd
...
3Pc Tenders Medium Combo - Spicy
...
comboSlot
...
Group
...
group_item_40961
...
Main Item
...
comboSlotOption
...
Group
...
option_group_item_40961
...
N/A
...
item
...
Item
...
item_40961
...
3Pc Tenders - Spicy
...
modifierGroup
...
Group
...
ModifierGroup_60
...
Sauces - 1 Included
...
modifier
...
Modifier
...
modifierMultiplier_1-00-163758
Default entry: For each Picker & Modifier Group, each group will have a property, “defaultSelection”. DefaultSelection will have an ID for an entry that is default for that group.
Types of Groups | Description | Display type |
---|---|---|
Menu | Group of Sections | List |
Section | Section is a broad container. It can contain pickers, items , combos as well as other sections | List |
Picker | Pickers allows an step by step selection process that ultimate resolve in Combos or Item. Pickers have only one immediate child, a reference to the first aspect. | Single entry |
Picker Aspect | Group of Picker Aspect Options | Select |
Picker Aspect Option | Group of picker Options - References the next aspect for the picker. The picker options of the last aspect reference the final selection result (combo/item) | Single entry |
Combo Slot | Group of Combo Slot Options | Select |
Combo Slot Option | References Combo Slot Option | Single entry |
Modifier Group | Group of Modifiers | Multi-select |
...
The POS or vendor needs to indicate what channel
they want to pull the menu for.
Menu Content Updated Webhook
Menu Content Updated events are dispatched when there are changes to content in the Content Management System (Sanity). This webhook provides information with what ids were created, updated or deleted considering the for any menu entriesdocument, configOffersEntriesincluding menu items, systemWideOffersEntries and rewardEntriesoffers and rewards. Sanity documents that aren’t menu-related won’t be broadcasted in this webhook.
It will also provide a versionId field so when retrieving the menu, you can compare it against the menu's metadata. This will let consumers know if the version they're consuming is up to date with the latest webhook call.
Info |
---|
Since This webhook boradcasts changes to the brand menu since the content is not store nor service mode specific, the store id or service mode aren’t present in the payload. |
...
Receiving data for each service mode is needed in all cases, even if the POS does not manage delivery and pickup availability separately.
Info |
---|
Note that the The PLUs for pick-up in the RBI platform and for in-restaurant menu uses the same PLUs as what’s being referred to as Pick-Up menu in the API documentation. Pick-up Service Mode Group is the same as In-restaurantorders (e.g. guests ordering at the front counter) should be the same. |
GET Store Menu PLUs Endpoint
This endpoint retrieves price & availability for all entries in the store's menu by PLU for a given service mode (delivery or pickup), as well as additional version metadata referring to the latest version of the menu.
...
This endpoint requires these parameters to return a response: storeId
, serviceMode
and channel
.
...
Store
...
For a given store, serviceMode and channel combination, this endpoint provides a history of versions starting from the provided version number. This history contains key/value pairs where the keys refer to a given version and the value contains one object with the created, updated and deleted information for the given version.
...
Menu
...
Version
...
Webhook
...
...
Store Menu
...
This endpoint allows updating multiple PLU pricing & availability values for multiple stores for a given service mode. In the request body, the partner can specify plus
, region
, channel
, serviceMode
and storeIds
. storeIds
supports an array of strings, whereas plus
is an array of objects supporting specifying mainly the values of availability, price and PLU.
Store Menu Version Webhook
Store Menu Version events are dispatched via this webhook when a store's menu changes. Menus can change for a variety of reasons. Some stores may update the availability of an item to make it unavailable for orders ("stock out"). Operators also make frequent changes to menu prices throughout the day, and at the brand-level menu entries are being added and removed continuously.
...
"created": [],
"deleted": [],
"updated": [],
Note that this webhook is different than to the https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5285970207/Menu+Management+-+API+Actions#Menu-Event-Webhook, Store Menu Version events also contain information on which data has changed and therefore removes the need to have a full sync of the menu for every update as that is a lengthy process.
This Webhook Event will contain the following message body:
Code Block |
---|
{
"brand": "BK",
"data": {
"created": [],
"updated": [],
"deleted": []
},
"region": "NZ",
"serviceMode": "pickup",
"storeId": "1234",
"version": 20231026212510630,
"eventTime": "2023-03-28T22:41:03.279Z",
"eventType": "MENU_PRICES_AVAILABILITY_UPDATE"
} |
There are two fields that require a deeper explanation here: version
and eventTime
.The version
is a ISO 8601 UTC Date Time without the digits. So on our example the version 20231026212510630
equates the ISO Date Time 2023-10-26T21:25:10.630Z
. For example, if you create PLU 501 at 2023-10-26T21:25:10.630Z
ISO Date, the current menu version received in this webhook will be 20231026212510630
. If another PLU is then updated, a new webhook event will be generated and a new version will be attached to the menu.
The eventTime
is a ISO Date which refers to the moment the webhook event was generated. It is not related in any way to the menu versioning. The arrays within the data object will contain objects relative to the created, updated or deleted in this specific version. Here’s a sample of what one of these objects look like:
Code Block |
---|
{
"availability": true,
"channel": "whitelabel",
"country": "US",
"endDate": 1673872934,
"hours": [
{
"start": "1700",
"end": "2100"
}
],
"plu": "string",
"price": 500,
"priority": 1,
"repetition": [
"Mo",
"Fr"
],
"startDate": 1673872934,
"serviceMode": "delivery",
"storeId": "641234",
"version": 20231026212510630
} |
\uD83D\uDCD8 Webhook Instructions
To see how it works, here is the step-by-step:
...
Create or update by making a PUT
call on the following Partners-API endpoint /api/v1/stores/{storeId}/menu/plus
. For the sake of our example, let’s use the following payload:
Code Block |
---|
{
"plus": [
{
"plu": "502",
"prices": [
{
"price": {
"currency": "USD",
"amount": 100
},
"channel": "WHITELABEL_IN_STORE"
}
]
}
]
} |
This will asynchronously trigger a few internal processes that will generate the following MENU_PRICES_AVAILABILITY_UPDATE
webhook event. This also generates a StoreMenuVersion
record in our database, which will be kept for 7 days.
...
GET Store Menu Diff Endpoint
For a given store, serviceMode and channel combination, this endpoint provides a history of versions starting from the provided version number. This history contains key/value pairs where the keys refer to a given version and the value contains one object with the created, updated and deleted information for the given version.
The https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5285970207/Menu+Management+-+API+Actions#Store-Menu-Version-Webhook will trigger whenever there’s a change to a store menu
That webhook provides all the information on the menu changes, including a version change number.
With that version change number, you can use the https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5285970207/Menu+Management+-+API+Actions#GET-Store-Menu-Diff-Endpoint to pull again a ‘report’ of what changed in the menu for a specific store, service mode and channel.
This endpoint is therefore usually used in conjunction with the https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5285970207/Menu+Management+-+API+Actions#Store-Menu-Version-Webhook .
Update (PUT) Store Menu PLUs Endpoint
This endpoint allows updating multiple PLU pricing & availability values for multiple stores for a given service mode and channel. In the request body, the partner can specify plus
, region
, channel
, serviceMode
and storeIds
. storeIds
supports an array of strings, whereas plus
is an array of objects specifying the values of availability, price and PLU.
Note |
---|
Every time there’s a change in pricing or availability for any store and service mode, the POS must call this endpoint immediately to update the P&A across the RBI tech platform. |
Menu Event Webhook
This webhook is a more generic webhook similar to the https://rbictg.atlassian.net/wiki/spaces/RDP/pages/5285970207/Menu+Management+-+API+Actions#Store-Menu-Version-Webhook .
...