Pular para o conteúdo principal
Além dos eventos de pedidos, uma loja com autoatendimento gera eventos do salão. Eles não pertencem a um pedido: dizem onde o cliente está para a equipe ir até ele.

​
Tipos de evento

O mesmo dispositivo só gera um novo CALL_WAITER depois de 3 minutos do anterior. Chamados repetidos dentro desse intervalo não viram eventos.

​
Estrutura do evento

Ao contrário dos eventos de pedido, eventos de indoor não têm orderId, orderURL nem orderType. Os campos de mesa e comanda só vêm quando têm valor.
​
uuid
obrigatório
Identificador único do evento. Use-o para descartar repetidos e no acknowledgment.
​
string
obrigatório
CALL_WAITER ou CLOSE_ACCOUNT.
​
uuid
obrigatório
A loja do evento.
​
datetime
obrigatório
Quando o evento foi criado.
​
string
Onde o cliente está. Num QR Code de mesa ou tablet, é o nome do place. Numa comanda, é o local que o cliente informou (por exemplo, o número da mesa), quando a loja pede essa informação.
​
string
O id do place, como indoor_qrcode_… ou indoor_tablet_…. Só vem quando o chamado partiu de um QR Code de mesa ou tablet.
​
uuid
O id da comanda.
​
string
O code da comanda.
​
string
O name da comanda, a identificação que a equipe vê.
​
string
Mesmo valor de tabCode, mantido por compatibilidade. Prefira tabCode.
​
object
Os mesmos campos de mesa e comanda acima, agrupados. Use os campos do primeiro nível.

​
Quais campos vêm em cada caso

​
Exemplos

​
Boas práticas

Identifique pelo id, mostre pelo nome. Use tabId e placeId para relacionar o evento ao seu cadastro, e tabName e placeName para a equipe saber onde ir.
Trate repetidos pelo eventId. A API pode entregar o mesmo evento mais de uma vez. Descarte o que já foi processado, mas envie o acknowledgment mesmo assim.
Feche o que foi pago. Depois de receber o pagamento de um CLOSE_ACCOUNT, você pode fechar a comanda para que ela não receba novos pedidos até ser reaberta.