Store Menu Update

Introduction

The middleware offers the possibility to send a payload for the complete update of a specific Glovo store, including overwriting the old configuration. This operation is carried out by sending a JSON payload to the middleware ETL, which then synchronizes with Glovo.

Asynchronous Process

The menu update operation is asynchronous and occurs in two stages:

1. Send payload — Send JSON to the update endpoint (Upload Menu). A success response means the payload was received and will be processed, not that the store was updated.

2. Check status — Call the check status endpoint (Check Status) to verify if the operation completed successfully.

STATE IS OBTAINED BY POLLING

The state of the operation is obtained by polling the check status endpoint. The update result is not pushed to a POS endpoint.

transaction_id

A successful upload response contains a transaction_id — a unique identifier per call that is never reused. It is only issued if the menu passes validation: if the upload returns 400, there is no transaction_id to poll.

Statuses

SUCCESS, PROCESSING, FETCH_MENU_INVALID_PAYLOAD, FETCH_MENU_SERVER_ERROR, FETCH_MENU_UNAUTHORIZED, NOT_PROCESSED, LIMIT_EXCEEDED, GLOVO_ERROR

Treat any status outside this list as non-final and keep polling.

The transition from PROCESSING to a final status has no guaranteed deadline. Poll with backoff and your own timeout, and re-upload if it is exceeded.

5 UPDATES PER DAY LIMIT

There is a limit of 5 menu update operations per day per store ID. If exceeded, the API returns an error.

To avoid reaching this limit, use individual update endpoints:

• Modify Product
• Modify Attribute
• Bulk Update