Sold out items
Up to 500 items in one call, with an optional time they come back. Customers see the item as sold out straight away, and cannot add it.
#One call, many items
Send PUT /v1/stores/{id}/items/availability. Name each item by your external_item_id, once it is mapped (see Item mapping), or by laayo_item_id.
PUT /v1/stores/27/items/availability
{ "items": [
{ "external_item_id": "MOMO-C-10", "available": false },
{ "external_item_id": "MOMO-V-10", "available": true }
] }From 1 to 500 items per call. More returns 422 validation_failed, so split a long list into calls of 500 or fewer.
#Back at a time
With "available": false, add back_at and the item comes back by itself at that time. It must be between 1 minute and 7 days ahead. Without it, the item stays off until you send true.
{ "items": [
{ "external_item_id": "MOMO-C-10", "available": false,
"back_at": "2026-11-02T10:00:00+05:45" }
] }#A result per item
Each item gets its own result, and one bad ID does not stop the others.
200
{
"data": {
"updated": 1,
"items": [
{ "ref": "MOMO-C-10", "laayo_item_id": 55102, "result": "updated",
"back_at": "2026-11-02T10:00:00+05:45" },
{ "ref": "PAN-CHI-DRY", "result": "not_found" }
]
}
}| result | Meaning |
|---|---|
updated | Changed on Laayo. |
unchanged | It was already like that. |
not_found | No Laayo item for this ID. Map it first. |
refused | Laayo would not change it; reason says why, for example item management is off for this store. |
#Safe to repeat
Sending the same state again answers unchanged, so a retry after a network drop is harmless. Sign the retry fresh: an identical request in the same second is refused as 401 replayed.
#Good habits
- Send changes as they happen, not on a timer. One call per tap is fine; batch when the kitchen marks many at once.
- Show not_found and refused rows to staff, so they can fix the mapping or ask the restaurant.
- When the owner uses Laayo's own controls, item calls return 409 owner_takeover. Keep the change and send it after the time in the message.