> ## Documentation Index > Fetch the complete documentation index at: /docs/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Documentação das APIs da DeliveryVip, em português. Regras que mais quebram integrações: (1) Merchant API: faça polling em GET /merchant/v3/events:polling no máximo a cada 30 s por token; confirme todo evento recebido com POST /merchant/v3/events/acknowledgment e corpo [{"id": ""}] (o campo lido é id, não eventId), inclusive eventos repetidos ou que o sistema não trata; deduplique por eventId; o evento é só um aviso, busque o pedido na orderURL. (2) Tokens client_credentials valem 24 h e não têm refresh_token: peça outro ao receber 401. (3) Webhooks: valide a assinatura HMAC sobre o corpo bruto e responda 2xx rápido; o polling é a reconciliação. (4) Open Delivery: host od.deliveryvip.com.br, um client_secret por loja, datas em UTC. (5) Fidelidade: o operador implementa 5 rotas assinadas com HMAC e chama o config push; o estorno precisa ser idempotente. (6) Partner API: scope dv.partner. Não invente endpoints: use a referência gerada das specs OpenAPI. # Eventos de indoor > A estrutura dos eventos de chamar garçom e fechar conta, e quais campos vêm conforme a origem do chamado. Além dos [eventos de pedidos](/docs/guides/merchant/order/fluxo-de-integracao/eventos-de-pedidos.md), 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 | Evento | Quando acontece | | - | - | | `CALL_WAITER` | O cliente tocou em "chamar garçom" no cardápio da mesa, do tablet ou da comanda. | | `CLOSE_ACCOUNT` | O cliente pediu para fechar a conta. | > [!NOTE] > > 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. **eventId** `uuid` *required* Identificador único do evento. Use-o para descartar repetidos e no [acknowledgment](/docs/guides/merchant/indoor/fluxo-de-integracao/acknowledgment-de-eventos.md). **eventType** `string` *required* `CALL_WAITER` ou `CLOSE_ACCOUNT`. **merchantId** `uuid` *required* A loja do evento. **createdAt** `datetime` *required* Quando o evento foi criado. **placeName** `string` Onde o cliente está. Num QR Code de mesa ou tablet, é o nome do [place](/docs/guides/merchant/indoor/places-api.md). Numa comanda, é o local que o cliente informou (por exemplo, o número da mesa), quando a loja pede essa informação. **placeId** `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. **tabId** `uuid` O `id` da [comanda](/docs/guides/merchant/indoor/comanda-api.md). **tabCode** `string` O `code` da comanda. **tabName** `string` O `name` da comanda, a identificação que a equipe vê. **tab** `string` Mesmo valor de `tabCode`, mantido por compatibilidade. Prefira `tabCode`. **metadata** `object` Os mesmos campos de mesa e comanda acima, agrupados. Use os campos do primeiro nível. ### Quais campos vêm em cada caso | Origem do chamado | `placeName` | `placeId` | `tabId`, `tabCode`, `tabName` | | - | :-: | :-: | :-: | | QR Code de mesa ou tablet | Sim | Sim | Só em `CLOSE_ACCOUNT` com comanda informada | | Comanda | Se o cliente informou | Não | Sim | ## Exemplos > [tab] CALL\_WAITER (comanda) > > ```json theme={null} > { > "eventId": "78b58a39-e222-44a4-a2c4-083c4837ed7d", > "createdAt": "2025-06-13T09:44:37-03:00", > "merchantId": "86fb4f52-573e-4869-9764-87238bcbad01", > "eventType": "CALL_WAITER", > "metadata": { > "tab": "0010", > "tabId": "9e9f4277-dba0-44d5-93e3-9a8b9050838d", > "tabCode": "0010", > "tabName": "Comanda 10", > "placeName": "1" > }, > "placeName": "1", > "tab": "0010", > "tabId": "9e9f4277-dba0-44d5-93e3-9a8b9050838d", > "tabCode": "0010", > "tabName": "Comanda 10" > } > ``` > [tab] CALL\_WAITER (mesa) > > ```json theme={null} > { > "eventId": "2f1c9a77-5b0e-4d3c-8f61-0c4e7d2b9a10", > "createdAt": "2025-06-13T09:50:12-03:00", > "merchantId": "86fb4f52-573e-4869-9764-87238bcbad01", > "eventType": "CALL_WAITER", > "metadata": { > "placeName": "Mesa 20", > "placeId": "indoor_qrcode_a7f4a8b1-8e6d-4614-be9a-b81b10a0de99" > }, > "placeName": "Mesa 20", > "placeId": "indoor_qrcode_a7f4a8b1-8e6d-4614-be9a-b81b10a0de99" > } > ``` > [tab] CLOSE\_ACCOUNT (mesa com comanda) > > ```json theme={null} > { > "eventId": "b99a3643-b6a5-408f-9f2f-29a1a6cc3cec", > "createdAt": "2025-06-13T10:55:14-03:00", > "merchantId": "86fb4f52-573e-4869-9764-87238bcbad01", > "eventType": "CLOSE_ACCOUNT", > "metadata": { > "tab": "0010", > "tabId": "9e9f4277-dba0-44d5-93e3-9a8b9050838d", > "tabCode": "0010", > "tabName": "Comanda 10", > "placeName": "Mesa 20", > "placeId": "indoor_qrcode_a7f4a8b1-8e6d-4614-be9a-b81b10a0de99" > }, > "placeName": "Mesa 20", > "placeId": "indoor_qrcode_a7f4a8b1-8e6d-4614-be9a-b81b10a0de99", > "tab": "0010", > "tabId": "9e9f4277-dba0-44d5-93e3-9a8b9050838d", > "tabCode": "0010", > "tabName": "Comanda 10" > } > ``` ## Boas práticas > [!TIP] > > **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. > [!TIP] > > **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. > [!TIP] > > **Feche o que foi pago.** Depois de receber o pagamento de um `CLOSE_ACCOUNT`, você pode [fechar a comanda](/docs/guides/merchant/indoor/comanda-api/acoes-das-comandas/fechar-para-consumo-uma-comanda.md) para que ela não receba novos pedidos até ser reaberta. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.