Skip to main content
GET
Em breve. O design está fechado mas este endpoint ainda não está implementado. Esta página descreve o contrato acordado para que os integradores possam se planejar antes do lançamento.
Retorna o último menu gerado de uma terna de uma loja — a mesma combinação que de outra forma chegaria via webhook menu.updated. Use Listar menus para descobrir quais ternas de uma loja têm hoje um.

Autenticação

string
obrigatório
Sua API key do Fire com scope menu:read. A key deve ser vendor-scoped (binding account + vendor) — keys sem vendorId são rejeitadas com 403.

Path params

string
obrigatório
UUID da loja (stores.id).

Query params

Não existe uma terna padrão — o Fire nunca adivinha uma por você. Os dois parâmetros são obrigatórios; se faltar algum, a resposta é 400.
string
obrigatório
Código do canal de venda (ex. KIOSK). Comparado sem diferenciar maiúsculas.
string
obrigatório
Código do tipo de fulfillment (ex. DINE_IN, TAKEAWAY). Comparado sem diferenciar maiúsculas.

Requisição

Resposta

object
Mesmo formato de data.menu no webhook menu.updated — list, categories, products, modifierGroups — com o mesmo enriquecimento que os agregadores recebem hoje (ids internos em list.storeId / list.channelId, categories[].assignedAt). Veja essa página para a referência completa de campos.
Mesmo formato também para canais do tipo X-MART. KIOSK (authType: XMART_LOGIN — veja channel.updated) é um deles: seu payload armazenado carrega ainda o número da loja e o id externo do canal, já dobrados no list acima.
object

Notas

O último menu gerado, mesmo que nunca tenha sincronizado

O Fire guarda o payload do menu antes de enviá-lo, e cada tentativa sobrescreve a anterior. Este endpoint retorna essa última versão independente de o envio ter chegado ao canal — o bloco sync diz se chegou. Exemplo: na segunda-feira KIOSK/DINE_IN sincroniza bem. Na terça os preços sobem e o envio falha. O GET de quarta-feira retorna a versão de terça com sync.status: FAILED e sync.syncedAt ainda apontando para segunda-feira.

Os esgotados são recalculados na leitura

O active do payload armazenado reflete o estado de esgotado no momento em que o menu foi gerado. Um produto marcado como esgotado depois chega ao canal pelo seu próprio webhook, sem reescrever o menu armazenado. Este endpoint recalcula active contra o estado de esgotado no momento da consulta, tanto em products[].active quanto nos produtos-opção de combos. Exemplo, nos dois sentidos: o menu é gerado às 10:00 com um item esgotado. Às 11:00 a marcação expira e o webhook reativa o item no canal. Um GET às 11:05 mostra o item ativo, igual ao canal — não esgotado, que é o único cenário que o payload armazenado sozinho mostraria.

Semântica de syncedAt

sync.syncedAt significa “última entrega bem-sucedida”, de forma consistente em todos os tipos de canal, incluindo os do X-MART. Um envio que falha nunca o avança.

Terna sem menu — 404 MENU_NOT_AVAILABLE

Se a terna existe mas não tem menu ou lista de preços atribuídos, a resposta é 404 MENU_NOT_AVAILABLE — diferente do 404 usado quando a própria loja não existe ou pertence a outro tenant. A loja já é validada contra sua key antes dessa verificação, então essa resposta nunca vaza dados de outro tenant.

Envio vazio — também 404 MENU_NOT_AVAILABLE

Quando o achatamento produz zero produtos vendáveis, o envio falha sem nunca chegar ao canal — mas o payload armazenado ainda fica com products: []. Este endpoint trata esse caso igual a uma terna sem menu: 404 MENU_NOT_AVAILABLE, em vez de um 200 com um menu vazio. Um menu vazio aqui seria indistinguível de “esta loja não vende nada”, que não é o que aconteceu — o menu nunca chegou ao canal. Listar menus ainda mostra a terna, com syncStatus: FAILED, para que o problema fique visível.

Relacionado

Listar menus

Descubra quais ternas de uma loja têm um menu gerado.

menu.updated

O webhook que este endpoint espelha — referência completa de campos para data.menu.

Obter loja

Leia uma loja específica por id.