Full menu update

A full update replaces the whole menu of a store with what you send. It is the main sync operation and, at the same time, the most expensive one — hence the daily limit.

The process, in two stages

The operation is asynchronous.

1. You send the payload

POST /api/v3/menu/upload
Authorization: your-api-key
Content-Type: application/json

{ "store_id": "gi20__001", "partner_name": "gi20", ... }

You get back a transaction_id.

A success response does not mean the menu is updated

It only means the payload was received and will be processed. Content errors surface at the next step.

2. You check the outcome

GET /api/v3/menu/checkstatus/{transaction_id}
Authorization: your-api-key

Status	What it means	What you do
SUCCESS	The menu was updated.	Nothing.
PROCESSING	Still processing.	Wait and poll again.
FETCH_MENU_INVALID_PAYLOAD	Invalid JSON, or not matching the schema.	Fix the payload. Validate it first.
NOT_PROCESSED	The integration is misconfigured.	Check the store and partner_name; if it persists, write to us.
LIMIT_EXCEEDED	You exceeded the daily limit for that store.	Wait, or use individual changes.
GLOVO_ERROR	A platform-side error.	Retry later.

When the status indicates an error, the response also carries details about the cause.

The alternative: we tell you

If you define an endpoint of type menu update result in the portal, you receive the final outcome without polling. See endpoints.

Validate before sending

POST /api/v3/menu/validate
Authorization: your-api-key
Content-Type: application/json

Checks the payload against the JSON schema and returns either an all-clear or the list of errors and warnings, with the line and column of each.

Validation does not count against the daily limit

It is free. Run it before every upload, especially from automated pipelines — otherwise a broken payload burns one of your five daily attempts.

The daily limit

5 full updates per day, per store

On the sixth you get LIMIT_EXCEEDED and the menu stays unchanged.

The limit is per store, not per POS. Five a day is plenty for genuine structural changes, but not for repeated syncing.

If you need frequent changes, do not resend the whole menu. Prices and availability go through individual or bulk changes, which carry no such limit.

Recommended pattern:

What changed	What you use
New products, categories, structure, names, images	full update
Price, availability	individual or bulk change

What the payload contains

The hierarchy and the identifier rules are in menu structure. The field specification is in the API reference.