The MENU_CONTENT_UPDATED is a newly created webhook that is responsible for informing partners about content updates.
This webhook considers changes that happen in elements inside of entries
, rewardEntries
, systemWideOfferEntries
and configOfferEntries
.
How many calls should I expect receiving daily in production?
Content does not change so often, so not many actually. Taking a look on content updates from a major market’s production environment, there were very few days with changes to content over the last month. The day where content was updated most times had 4 updates.
\uD83D\uDCCB Webhook Payload
The webhook contains the following payload:
{ "brand": "BK", "channel": "whitelabel", "data": { "created": [ "item_67168" ], "deleted": [ "item_67169" ], "updated": [ "item_67170" ] }, "eventTime": "1991-02-11T20:30:19Z", "eventType": "MENU_CONTENT_UPDATED", "region": "US", "version": 20240108163635030 }
The two most relevant information are:
version - this is a ISO 8601 with only numeric values. This is an orderable value that refers to the content of the menu. This very same information is present in Get Store Menu endpoint meta attribute and it will allow Partners to know if the menu they’re retrieving are up to date with the webhook call they received.
data - contains the ids of elements that were created, deleted or updated in the menu.
\uD83D\uDCD8 Instructions
Subscribe to MENU_CONTENT_UPDATED webhook.
Once subscribed, whenever there are changes in Sanity, you’ll receive a message with the ids of elements that were changed and the version of this content.
After a few minutes, make a call to Get Store Menu to retrieve the menu of a store and check the meta attribute against the version received in the Webhook.
If the meta version is smaller than the webhook version, the retrieved menu wasn’t updated yet. Please, wait a few minutes while the changes propagate on our end.
If the meta version is equal to the webhook version, the retrieved menu matches the webhook call.
If the meta version is greater than the webhook version, the retrieved menu has newer changes that you should’ve been notified about.
The menu changes propagate asynchronously on our end. It is possible that by the time you start to sync the store menus, the changes haven’t propagated on our end for all stores. It’s highly advised to wait a few minutes before syncing the menus and always check if the meta attribute in the version matches the version received in the webhook payload.
\uD83D\uDCCB Example
For this example let’s use BK ES dev environment and checking the menus for store 1005 on pickup serviceMode. The item to be changed is Regular Fries - item_10242.
Make a call to
PUT https://euc1-dev-bk-partners-admin.rbictg.com/api/v1/integration
with the payload{ "webhooks": [ { "type": "MENU_CONTENT_UPDATED", "url": "https://mock-webhook-url.com" } ] } }
Before making any changes, let’s make a call to retrieve a store menu to compare later on.
GET https://euw3-dev-bk-partners-api.rbictg.com/api/v1/stores/1005/menus/pickup/whitelabel
. This response has the following version meta attribute. It has the following version20240311115808290
.
Our Regular Fries:
Make a change to Regular Fries - item_10242 in Sanity.
Once content was rebuilt, the following message was received meaning that on version
20240312134902530
there were updates toitem_10242
To sync the store menus, make a call to get the full store menu of a store, in this example we’re calling
GET https://euw3-dev-bk-partners-api.rbictg.com/api/v1/stores/1005/menus/pickup/whitelabel
. Then check the version attribute in meta. In this case the versions match, so no need to wait a few minutes and re-tryNow let’s look for changes on
item_10242
, we can confirm that the weight changed when compared to the initial version.
You can then, proceed syncing the menus for other stores/serviceModes.