> ## Documentation Index > Fetch the complete documentation index at: https://docs.fire.rest/llms.txt > Use this file to discover all available pages before exploring further. # Registro de alterações > Atualizações recentes na documentação e na referência da API.
Assine as atualizações
Receba um e-mail sempre que uma nova entrada for publicada — eventos novos, mudanças incompatíveis e atualizações da referência da API. Cancele com um clique.
Assinar
## 15 de agosto de 2026 — O bloco fiscal: identificadores por país, cancelamento e provedor `fiscalRepresentation` deixa de ter campos fixos por país e passa a levar o documento **vigente** do pedido, com os anteriores em `history`. * **Breaking** — `sequential`, `serie` e `claveAcceso` não são mais campos do bloco. Os identificadores do órgão vivem agora em **`countryData`**, com o vocabulário do país que numerou: `claveAcceso`, `establecimiento`, `puntoEmision`, `secuencial` e `ambiente` no Equador; `numeroControl`, `numeroFactura` e `serie` na Venezuela. **Percorra as chaves, não as indexe**: um canal que leia `countryData.claveAcceso` direto funciona no Equador e quebra com o primeiro país que entrar. Os campos que significam o mesmo em qualquer país —`documentNumber`, `issuedAt`, `authorizationMode`, `numberingStatus`— não se moveram. * **`history`** e **`compensates`** — quando um cancelamento numera, a nota de crédito passa a ser o documento do topo, `compensates` aponta para a nota de venda que ela cancela, e a nota de venda inteira desce para `history`. Cada entrada de `history` tem **as mesmas chaves** que o bloco acima, então se leem igual. * **`environment`** — em qual ambiente o Fire numerou: `SANDBOX` ou `PRODUCTION`. É nosso, não do órgão; o do órgão continua viajando dentro de `countryData` com o próprio código. * **`providerCode`, `providerIdentity` e `providerMetadata`** — antes eram um único objeto que misturava três coisas. `providerCode` é o nosso identificador de adaptador; `providerIdentity` é o bloco do provedor (`name`, `version`, `reference`) e **tem forma**; `providerMetadata` é uma bolsa **opaca** e não se deve programar contra suas chaves. A resposta do endpoint de numeração devolve agora exatamente os mesmos três campos, com os mesmos nomes. Se a sua conciliação assume que `documentNumber` é sempre o da venda, revise-a: após um cancelamento o número do topo é o da nota de crédito. O que o cliente levou impresso não se perde — está em `history` — mas é preciso ir buscá-lo lá. Documentado em [`order.opened`](/pt/events/order-opened), [`order.completed`](/pt/events/order-completed), [`order.cancelled`](/pt/events/order-cancelled), [`order.invoiced`](/pt/events/order-invoiced), [`order.reversed`](/pt/events/order-reversed), na [referência do endpoint](/pt/api-reference/fiscal-documents) e no guia [Integrar um ponto de venda](/pt/guides/fiscal-integration). Atualizado em **EN / ES / PT**. ## 13 de agosto de 2026 — A numeração fiscal agora viaja em todos os eventos do pedido Os pedidos que o Fiscal Gateway numerou antes da injeção agora levam esses identificadores em todos os seus eventos, então não é mais preciso uma segunda chamada para imprimir ou conciliar. * **`data.fiscalRepresentation`** — série, sequencial, número do documento, chave de acesso e o QR (`graphic`), exatamente como foram impressos no caixa. **A chave viaja sempre**: chega em `null` quando não se tentou numerar — agregadores, países sem representação fiscal, ou numeração desativada — e traz o bloco quando houve tentativa. Ramifique pelo valor (`if (data.fiscalRepresentation)`), não pela presença da chave. Trazer o bloco significa **que se tentou numerar, não que foi numerado**: `numberingStatus` diz como a tentativa terminou e `failure` por quê, quando não terminou bem — uma venda cobrada que ficou **sem comprovante fiscal** chega com os identificadores em `null` e o motivo em `failure`. Trazer o bloco **não** significa que o comprovante esteja autorizado: o veredito do órgão continua em `lastKnown.fiscal.status`. O bloco nunca muda, nem depois que o órgão autoriza ou rejeita. * **`data.lastKnown.fiscal.sourceEvent`** — agora informa a procedência real em vez de deduzi-la do status. Um `processing` semeado na injeção era reportado como `fiscal.callback` sem que nenhum callback tivesse ocorrido; agora diz `order.injected`. Contemple o valor novo se você ramifica por este campo. * Documentado em [`order.opened`](/pt/events/order-opened), [`order.completed`](/pt/events/order-completed), [`order.invoiced`](/pt/events/order-invoiced) e [`order.cancelled`](/pt/events/order-cancelled). Atualizado em **EN / ES / PT**. ## 11 de agosto de 2026 — BOH API: qty\_base derivado no servidor com item\_unit\_id Nas linhas de pedidos de compra (`POST /procurement/orders`, `add-lines` e atualização de linha), `qty_base` agora é opcional quando a linha referencia `item_unit_id` — não apenas `unit_code`. O servidor deriva `qty_base = qty × factor_to_base` a partir da unidade referenciada, então integradores externos que referenciam uma unidade de compra por UUID não precisam mais conhecer nem recalcular o fator de conversão. Se você enviar um `qty_base` explícito mesmo assim, o BOH o valida contra o valor derivado (tolerância 0.001) e retorna `purchase_order_qty_base_mismatch` (422) em caso de divergência — mesmo comportamento do `unit_code`. Se `item_unit_id` não resolver para uma unidade ativa e `qty_base` foi omitido, a resposta agora é o erro tipado `item_unit_not_found` (404). Atualizado em **EN / ES / PT**. *** ## 11 de agosto de 2026 — BOH API: resolução de estabelecimento por ID fiscal em pedidos de compra (Fase 19) `tax_id` é agora um campo de primeira classe nos estabelecimentos do BOH (RUC, CNPJ, CUIT, NIT, RUT, RFC ou qualquer código fiscal até 64 caracteres). É opcional, não único, e aceito em `POST /identity/stores` e `PATCH /identity/stores/{id}`. Ao criar um pedido de compra via API você pode identificar o estabelecimento receptor com qualquer um destes três campos mutuamente exclusivos: * **`store_id`** — UUID interno (sem alterações). * **`external_store_id`** — identificador externo cruzado. * **`store_tax_id`** *(novo)* — identificador fiscal. Retorna `422` com `purchase_order_store_tax_id_ambiguous` se vários estabelecimentos ativos compartilharem o mesmo valor (ex.: CNPJ compartilhado entre filiais) — nesse caso use `store_id` ou `external_store_id`. Combinado com os campos ERP das Fases 17–18, os ERPs podem criar pedidos de compra sem conhecer nenhum UUID interno. Atualizado em **EN / ES / PT**. *** ## 11 de agosto de 2026 — BOH API reestruturada: uma página por endpoint A aba de BOH API foi completamente reestruturada em páginas individuais por endpoint. Cada endpoint tem agora sua própria entrada no menu mostrando o método HTTP (`GET`, `POST`, `PATCH`, `DELETE`), exemplos interativos de request/response, e um botão **Experimentar** para testar o endpoint diretamente na documentação. A nova estrutura cobre os 63 endpoints em 6 seções: Identidade, Catálogo, Receitas, Operações, Compras e Webhooks. Atualizado em **EN / ES / PT**. *** ## 11 de agosto de 2026 — BOH API: ordens de compra — resolução por supplier\_sku e external\_user\_id Duas adições à referência de [ordens de compra](/pt/boh-api/procurement#ordens-de-compra): **`supplier_sku` nas linhas** — um terceiro identificador de item para integração com ERPs. Em vez de `item_id` ou `external_item_id`, envie `supplier_sku` (sem diferenciar maiúsculas) e o BOH resolve o item diretamente do catálogo do fornecedor da ordem, derivando `base_unit_id` automaticamente. Erro: `purchase_order_supplier_sku_not_found` (404). **`external_user_id` na criação** — o identificador do usuário chamador agora é aceito ao criar uma ordem de compra e armazenado como `actor_external_user_id`. Anteriormente o campo era ignorado silenciosamente. Atualizado em **EN / ES / PT**. *** ## 10 de agosto de 2026 — Manuais KDS: emparelhamento, board do operador, riscar linhas e defaults de display Manuais KDS novos e atualizados com o trabalho recente do fire-kds: **[Emparelhar um dispositivo](/pt/manuals/kds/device-pairing)** — guia nova. Cadastrar TVs de cozinha com código de 6 dígitos em **KDS → Todas as lojas**, gerenciar terminais emparelhados e entender o logout de dispositivo vs e-mail. **[Board do operador](/pt/manuals/kds/operator-board)** — guia nova. Lista/detalhe do supervisor com temporizadores ao vivo, filtros, códigos de coleta e sobrescritas cancelar / pronto / despachar. **[Ações na tela](/pt/manuals/kds/screen-actions)** — riscar linhas antes do bump, despacho aguardando montagem, alerta de pedido novo e configurações de display mais ricas (defaults da loja, nome do cliente por canal/fulfillment). **[Painel de senhas](/pt/manuals/kds/waitlist)** — filtros de fulfillment (ex. ocultar delivery do painel). **[Visão geral](/pt/manuals/kds/admin-overview)** — opções KDS no nível da loja (defaults de display, line strike, motivos de cancelamento) e links para as novas guias. Atualizado em **EN / ES / PT**. *** ## 7 de agosto de 2026 — BOH API: operações, identidade, sincronização em massa e endpoints de compras A referência da [BOH API](/pt/boh-api/introduction) agora cobre o conjunto completo de endpoints para construir uma integração completa: **[Identidade](/pt/boh-api/identity)** — nova seção. Descubra o contexto da sua conta (`GET /identity/me`), liste vendors e gerencie estabelecimentos e fornecedores (criar, atualizar, arquivar/desarquivar). **[Catálogo: Sync em massa](/pt/boh-api/catalog-sync)** — nova seção. Três endpoints `PUT` de sincronização em massa: * `PUT /catalog/units` — upsert de unidades por `code + unit_group_code`; unidades globais são ignoradas sem erro. * `PUT /identity/suppliers` — upsert de fornecedores por `external_supplier_id`. * `PUT /catalog/classifications/assignments` — substitui todas as atribuições de classificação de um item ou estabelecimento de forma atômica. **[Operações](/pt/boh-api/operations)** — nova seção. Cobre todos os tipos de movimentação de estoque: * Recebimentos de mercadoria (criar, listar, obter) — suporta `external_store_id` e `external_supplier_id` para não precisar de UUIDs prévios. * Contagens de estoque (criar, listar) — escopo `FULL` ou `PARTIAL`, com `area_breakdown` para sessões de contagem colaborativa por áreas. * Perdas (criar, listar) — linhas por item, tag de itens ou snapshot de sub-receita. * Transferências (criar, listar) — débito/crédito atômico entre estabelecimentos. * Lotes de produção (criar, listar, obter) — registra execuções de receita com output real e overrides de ingredientes opcionais. * Rastreamento de transações (status, listar) — consulte qualquer escrita assíncrona pelo seu `tracking_id`. **[Compras](/pt/boh-api/procurement)** — nova seção. Ciclo de vida completo de ordens de compra (`POST /procurement/orders` com chave de idempotência, listar/obter, enviar, confirmar, adicionar/atualizar/remover linhas, cancelar, fechar e status de atendimento), além de `PUT /procurement/par-levels` para upsert de metas de estoque por item/estabelecimento e `GET /procurement/suggested-order` para obter quantidades de reabastecimento sugeridas. As ordens de compra também suportam **integração com ERPs por meio de identificadores externos**: `external_supplier_id`, `external_item_id` e `unit_code` resolvem os registros internos no servidor (sem necessidade de UUIDs do BOH), `external_reference` marca a ordem com o seu código de documento (filtrável na listagem) e as linhas aceitam valores informativos (`tax_amount`, `delivery_amount`, `total_amount`, `markup_amount`). Atualizado em **EN / ES / PT**. *** ## 7 de agosto de 2026 — Manuais BOH: linhas por canal, contagens colaborativas, moeda da conta Três atualizações nos manuais do usuário BOH refletindo mudanças recentes no produto: **Receitas — linhas com escopo por canal (Fase 16)** O modelo de "complementos por serviço" foi substituído por **linhas com escopo por canal** em uma única receita. Cada linha agora tem um campo opcional `service_codes`: * Linhas sem `service_codes` são **gerais** e sempre se aplicam. * Linhas com `service_codes: ["DELIVERY"]` só se aplicam quando o canal do pedido corresponde. * Uma única receita publicada por produto e loja substitui o par BASE + COMPLEMENT anterior. Atualizado: [Receitas — Linhas com escopo por canal](/pt/manuals/boh/recipes#linhas-com-escopo-por-canal). **Contagens — sessões de contagem colaborativa** Nova seção documentando as **sessões de contagem em campo**: vários dispositivos podem contar diferentes áreas de inventário da mesma loja simultaneamente. Cada dispositivo reivindica uma área exclusiva, conta e a marca como pronta. O dispositivo administrador finaliza a sessão, que cria uma contagem normal. Atualizado: [Contagens — Sessões de contagem colaborativa](/pt/manuals/boh/stock-counts#sessoes-de-contagem-colaborativa). **Catálogo — moeda da conta** Nova seção documentando a configuração de **moeda da conta**. Cada conta BOH agora tem uma moeda ISO 4217 padrão (definida em Conta e acessos → Configuração da conta) usada em custos de abastecimento, preços de itens de fornecedor e relatórios. Atualizado: [Catálogo — Moeda da conta](/pt/manuals/boh/catalog#moeda-da-conta). Atualizado em **EN / ES / PT**. *** ## 7 de agosto de 2026 — Listas de preços: novo manual do usuário As listas de preços permitem trabalhar com preços diferentes por canal, loja ou campanha sem manter cada um na mão. O manual já está disponível: **[Listas de preços](/pt/manuals/backoffice/price-lists)**. * **Listas conectadas** — uma lista pode seguir uma lista base. Você muda o preço uma vez e ele chega a todas; o produto que precisar de um preço próprio o define e deixa de segui-la, apenas para aquele produto. As fórmulas como `=P*1.15` ficam vivas: quando a base muda, a lista se recalcula sozinha. * **Preços por contexto** — o mesmo produto pode valer diferente dentro de um combo. Esses preços ficavam escondidos na configuração de cada combo; agora aparecem e são editáveis na própria linha do produto, com o percentual em relação ao preço avulso. * **Edição em massa com arredondamento comercial** — aplique um percentual ou um valor a muitos produtos de uma vez, alcançando também os preços dentro de combos, e arredonde para `.99`, `.90` ou número inteiro para não acabar vendendo a 13,42. * **Modo comparação** — sobreponha outra lista como referência para ver, produto a produto, onde as duas se separam. * **Alcance antes de salvar** — um resumo de quais listas conectadas recebem a mudança e, principalmente, **qual não recebe nada** porque todos os produtos que você tocou têm preço próprio ali. * **Conectar uma lista existente** — uma lista que nasceu como cópia e ficou desatualizada pode ser conectada a uma lista base. O que coincide com a base passa a segui-la, o que tem preço próprio fica como está: ao conectar, nenhum preço se move. Os preços por horário (*day-parting*) ainda não estão disponíveis, e esta fase trabalha sobre o preço final com impostos incluídos — o preço líquido e o de referência vêm depois. O manual deixa os dois limites explícitos. *** ## 6 de agosto de 2026 — Batimentos de saúde de quiosques, KDS e caixas Quiosques, telas KDS e caixas POS já podem informar que estão vivos, e o painel de disponibilidade do Fire lê a frota a partir desses batimentos. O endpoint é [`POST /external/component-health`](/pt/api-reference/component-health) e exige uma API key com o escopo `component-health:write`. * **[Saúde de componentes](/pt/api-reference/component-health)** — um batimento por ciclo com `componentType`, `componentId`, `storeId` e `status`. Opcionais: `sentAt`, `offlineSince`, `degradedReason`, `appVersion` e um `details` livre. Responde `204 No Content`. * **`X-Heartbeat-Interval`** — cada `204` traz a cadência vigente, em segundos. Adote-a no próximo ciclo: é assim que o intervalo é reconfigurado sem publicar uma release. * **O `componentId` precisa ser estável** — se mudar entre reinícios, para o Fire é outro componente: o antigo é baixado após 7 dias e o novo começa sem histórico. * **`degradedReason` usa um vocabulário comum** — `printer_down`, `pinpad_down`, `backend_unreachable`, `queue_backlog`, `peripheral_other`. As chaves de `details` para `kds_station` ainda serão combinadas com o time de KDS. `status` aceita apenas `online` e `degraded`. Não existe `down`: um equipamento não pode se declarar morto — o Fire infere a queda pela ausência do batimento, após dois intervalos perdidos. Atualizado em **EN / ES / PT**. ## 4 de agosto de 2026 — Novo campo `assignedAt` em eventos de menu e produto `menu.updated v2` e `product.updated` agora levam `assignedAt` em cada categoria e produto. * **`categories[n].assignedAt`** e **`products[n].additionalInfo.assignedAt`** — data em que a entidade entrou no menu, ISO 8601 UTC, sem milissegundos. É um dado de **pertencimento**, não de edição: não muda com edições de preço, nome, imagem ou ordem; muda (data nova) quando o item é removido do menu e adicionado novamente. Casos extremos completos em [`menu.updated` → Data de atribuição ao menu](/pt/webhook-reference/menu-updated-v2#data-de-atribuição-ao-menu). Não viaja em [`product.price_updated`](/pt/webhook-reference/product-price-updated) nem em [`product.availability_changed`](/pt/webhook-reference/product-availability-changed) — esses eventos transmitem apenas seu delta. * **[`menu.updated`](/pt/webhook-reference/menu-updated-v2) / [`product.updated`](/pt/webhook-reference/product-updated) usam `taxInfo`** (não `taxesInfo`), **`type: PRODUCTO`** para itens padrão, e **`modifierGroups[n].type: RADIO`** para grupos de seleção única (`CHECKBOX` para múltipla). * **`storeId` é o UUID interno da loja** (`stores.id`), não o `store_number` — mesma convenção em `menu.updated`, `product.updated`, `product.price_updated` e `product.availability_changed`. * **O `priceInfo` de `product.price_updated` não compartilha forma com o `priceInfo` de catálogo** de `menu.updated` / `product.updated` — é o preço de venda recém-salvo com seu desconto, não preços de catálogo. `channelReferenceName` significa o **fulfillment** (`delivery`, `pickup`) em `list.stores[n].channels[n]` de `menu.updated`, mas o **canal de vendas** (`iFood`, `Rappi`) no mesmo nome de campo de `product.updated`, `product.price_updated` e `product.availability_changed`. Mesma chave, duas coisas diferentes dependendo do evento. Atualizado em **EN / ES / PT**. ## 4 de agosto de 2026 — Assinatura por e-mail do registro de alterações Agora você pode receber um e-mail sempre que uma nova entrada for publicada nesta página. Assine pelo botão acima — a lista é gerenciada pelo Buttondown, então nenhum endereço fica guardado na documentação, e um clique em qualquer e-mail cancela a assinatura. * **Um e-mail por entrada, nos três idiomas** — English, Español e Português chegam juntos na mesma mensagem, então não há nada a escolher. * **Só uma entrada nova dispara o envio** — corrigir um erro em algo já publicado nunca reenvia. Atualizado em **EN / ES / PT**. ## 2 de agosto de 2026 — `order.opened` e os blocos de pagamento diferido Cada evento avança em **sua própria linha de versão** — não há um número de contrato global: | Evento | Versão | | ----------------------------------------------- | ------------------------------------- | | [`order.opened`](/pt/events/order-opened) | **v1** (evento novo, primeira versão) | | [`order.completed`](/pt/events/order-completed) | v1 → **v1.1** | | [`order.invoiced`](/pt/events/order-invoiced) | v1 → **v1.1** | | [`order.cancelled`](/pt/events/order-cancelled) | v2 → **v2.1** | Tudo o que foi adicionado é retrocompatível (blocos novos sobre um shape existente). Nada aqui altera um campo que você já lê, e o contrato anterior de cada evento continua publicado atrás da sua aba de versão. * **Novo evento [`order.opened`](/pt/events/order-opened)** — dispara quando um pedido é injetado **já aberto**: ele existe, a cozinha pode começar, ninguém pagou ainda. Carrega o mesmo snapshot V4 que `order.completed`. **Não** dispara para pedidos injetados como `COMPLETED` ou `CANCELLED`. Este evento não tem v0 — nasceu no v1. * **`data.policy.deferredPayment`** — adicionado aos **quatro** eventos de pedido (`order.opened`, `order.completed`, `order.invoiced`, `order.cancelled`). Diz se o pedido pode ser cozinhado, faturado ou despachado **antes** do pagamento. Resolvido uma vez na injeção e carimbado imutável; todos os eventos seguintes repetem o mesmo valor. * **`data.lastKnown`** — adicionado a esses mesmos quatro eventos. Foto orientativa do estado de cozinha e fiscal. **Nunca condicione uma ação irreversível a este campo** — pode vir `null` ou desatualizado, e o próprio Fire o ignora e relê da fonte antes de emitir qualquer coisa. Em `order.opened`, `payments.paymentMethods[]` é o que o PDV **declarou**, não o que foi cobrado — `transactionStatus` vem como `PENDING` e `transactionId` normalmente vazio. O Fire sobrescreve o array com os tenders reais quando a cobrança entra, e emite `order.completed`. Ler o meio declarado como evidência de recebimento é o erro mais comum com este evento. Atualizado em **EN / ES / PT**. ## 22 de julho de 2026 — Manuais do usuário BOH Adicionada a seção **BOH** na aba Manuais do usuário, cobrindo a administração do inventário back-of-house pelo Fire backoffice: * **[Visão geral e conceitos](/pt/manuals/boh/admin-overview)** — como catálogo, receitas, abastecimento, movimentos, contagens e relatórios se relacionam; o fluxo de estoque; mapa do menu BOH. * **[Lojas e fornecedores](/pt/manuals/boh/stores-suppliers)** — lojas BOH vinculadas ao Restaurant OS e fornecedores com vínculos item–fornecedor (preço, unidade de compra, SKU). * **[Catálogo](/pt/manuals/boh/catalog)** — grupos de unidade e unidades, itens, etiquetas de itens intercambiáveis (FIFO / FEFO / prioridade / maior estoque), classificações. * **[Receitas](/pt/manuals/boh/recipes)** — receitas de venda, produção e subreceitas; ciclo rascunho → publicada → arquivada; linhas por canal; simulador de venda. * **[Abastecimento](/pt/manuals/boh/procurement)** — programações de recebimento, ciclo de vida dos pedidos de compra, níveis par e pedido sugerido. * **[Recebimentos e devoluções](/pt/manuals/boh/goods-receipts-returns)** — recebimentos de mercadoria (entrada de estoque, vínculo ao pedido de compra, sobre-recebimento) e devoluções ao fornecedor. * **[Perdas e consumos internos](/pt/manuals/boh/waste-consumption)** — catálogo de motivos de perda, eventos de perda, consumos internos. * **[Transferências e produção](/pt/manuals/boh/transfers-production)** — transferências entre lojas e lotes de produção com rendimento. * **[Contagens](/pt/manuals/boh/stock-counts)** — áreas de inventário, contagens completas/parciais e o app móvel de contagem. * **[Relatórios](/pt/manuals/boh/reports)** — usos e consumos, perdas, rendimento de produção e saldo em uma data. As 10 páginas publicadas em **EN / ES / PT**. *** ## 13 de julho de 2026 — Cancelar pedido: campo `cancellationType` Adicionado o campo opcional `cancellationType` (`string`) ao body de [Cancelar pedido](/pt/api-reference/cancel-order). Quando enviado, o ID ou código do motivo de cancelamento do catálogo é persistido no pedido e reportado ao gateway de pagamento. Atualizado em **EN / ES / PT**. ## 3 de julho de 2026 — Injetar pedido: distribuição de desconto em combo Adicionada a seção [Descontos de combo](/pt/api-reference/orders#descontos-de-combo) na referência de Injetar pedido. Quando um produto `COMBO` tem preço do contêiner igual a 0, o `discountsValue` do combo **não deve** ser colocado na linha do contêiner (produz totais negativos). Em vez disso, deve ser distribuído proporcionalmente entre os `selectedModifiers`: * `discount_i = ROUND(D × (base_i / B), 2)` — parcela proporcional por modificador * Cada modificador deve manter `subtotalIncludeDiscounts >= 0` e `total >= 0` após o desconto * O contêiner COMBO deve ter todos os campos de preço em `0` * `SUM(modifier.totalPrice.discountsValue)` deve ser igual ao desconto total do combo Inclui exemplo JSON antes/depois (desconto BRL 17,94 em um combo de 7 itens, base BRL 89,68) e tabela de distribuição completa. Atualizado em **EN / ES / PT**. ## 29 de junho de 2026 — Manuais do usuário KDS Adicionada a seção **KDS** na aba Manuais do usuário, cobrindo tanto o uso pelo operador quanto a administração pelo backoffice: * **[Visão geral e conceitos](/pt/manuals/kds/admin-overview)** — como lojas, estações, telas, roteamento, dispositivos e impressão se relacionam; dois tipos de estação (produção vs convergência); padrões de cozinha (somente montagem, KITCHEN, multi-estação). * **[Configurar uma loja](/pt/manuals/kds/store-setup)** — aplicar um modelo (assistente de blueprint) ou configurar do zero; ordem recomendada das etapas. * **[Estações](/pt/manuals/kds/stations)** — campos, regras opcionais por canal / serviço / tipo de item, criação passo a passo. * **[Telas](/pt/manuals/kds/screens)** — identificador de dispositivo, criar e atribuir estações, relação tela ↔ estação. * **[Roteamento](/pt/manuals/kds/routing)** — camadas de decisão (roteamento → regras → distribuição → convergência), modos de distribuição, exemplo multi-estação. * **[Periféricos, impressão e validação](/pt/manuals/kds/peripherals-printing)** — teclados, impressão de retirada (uma tela por loja), cancelamento de pedidos, checklist de go-live e rotas de referência. * **[Ações na tela](/pt/manuals/kds/screen-actions)** — avançar, reter/liberar, desfazer, cancelar, paginação, menu de configurações e atalhos de teclado. * **[Tela de espera](/pt/manuals/kds/waitlist)** — tela para clientes (áreas em preparo / pronto, destaque ao ficar pronto, paginação automática). As 8 páginas publicadas em **EN / ES / PT**. ## 22 de junho de 2026 — Novo guia: Estrutura de produtos · Publicação de cardápios atualizada ### Novo guia: Estrutura de produtos Nova página [Estrutura de produtos](/pt/guides/combo-products) na aba Guias — cobre o tipo `COMBO` e os overrides de modificadores: * **Tipo COMBO** — `priceInfo.price` é sempre `0`; usar `priceInfo.referencePrice` como preço de cabeçalho do produto. * **Preço de referência** — soma de (opção mais barata × `minOptions`) em cada grupo de modificadores obrigatório (`minOptions ≥ 1`). * **Overrides de modificadores** — `productModifiers[n].overrides` define um preço diferente para uma opção dentro de um combo específico; tem precedência sobre o preço base do produto em `products[]`. * **Preços delta** — grupos obrigatórios exibem `+R$ X` acima do baseline; grupos opcionais exibem o preço cheio do add-on. ### Guia de publicação de cardápios * Removida a seção `menus.sync` — esse evento não existe mais. * Corrigido o formato do payload: `event` é agora um objeto aninhado (`id`, `type`, `executionId`, `createdAt`), não campos no nível raiz. * O passo de verificação de assinatura agora especifica que o signing secret é obtido em **Integrações de agregadores** no dashboard do Fire. * Adicionada seção de estrutura do cardápio com descrição de `list`, `categories`, `products` (tabela de tipos) e `modifierGroups`. Atualizado em **EN / ES / PT**. ## 15 de junho de 2026 — `order.completed` — novos campos do método de pagamento Adicionados 4 campos em `payments.paymentMethods[n]` no evento [`order.completed`](/pt/events/order-completed). Todos são nullable e já estão em produção. * **`idAuth`** (`string | null`) — ID de autorização do processador de pagamento (ex.: SiTef `IdAuth`). Diferente de `authorizationCode`. * **`receiptCustomer`** (`string | null`) — Texto completo do comprovante para o cliente; pode ser multilinha. * **`receiptMerchant`** (`string | null`) — Texto completo do comprovante para o estabelecimento; pode ser multilinha. * **`acquirer.cnpj`** (`string | null`) — CNPJ da credenciadora de pagamento — apenas Brasil. Atualizado em **EN / ES / PT**. ## 15 de junho de 2026 — Campos de detalhe do método de pagamento Adicionados 5 campos opcionais em `payments.paymentMethods[n]` em [Injetar pedido](/pt/api-reference/orders): * **`id_auth`** (`string | null`) — Número de autorização NFCE (SiTef 952 / IdAuth). * **`receipt_customer`** (`string | null`) — Via do cliente: texto do comprovante impresso para o portador (SiTef 121 / ReceiptCustomer). * **`receipt_merchant`** (`string | null`) — Via do estabelecimento: texto do comprovante impresso para o lojista (SiTef 122 / ReceiptMerchant). * **`acquirer.cnpj`** (`string`) — CNPJ da credenciadora para NFCE (SiTef 950 / CNPJAuth). `acquirer` fica documentado como nullable — envie `null` para métodos sem credenciadora. * **`card.media`** (`string`) — Tipo de leitura do cartão: `CHIP`, `MAGNETIC`, `NFC`, `MANUAL` (SiTef 2090 / Media). `card` fica documentado como nullable — envie `null` para métodos sem cartão. Todos os campos são opcionais e já estão implementados no validador. Atualizado em **EN / ES / PT**. ## 14 de junho de 2026 — Webhook de status de pedido do agregador * **Novo webhook de entrada [`POST /v1/webhooks/aggregators/order-status`](/pt/api-reference/aggregator-order-status)** — seu agregador de delivery (Rappi / Uber / Didi / iFood / PedidosYa / Glovo…) faz POST com o status de entrega do pedido conforme ele avança (`courier_assigned` → `on_route` → `delivered`…). O Fire espelha o status mais recente em `orders.aggregator` e registra cada evento. * **O status é passthrough** — nenhum enum é imposto; os rótulos do próprio agregador são armazenados **literalmente**, e o status **atual** é o que tem o **`occurredAt` mais recente** (sem guard anti-regressão). Rótulos traduzidos amigáveis são resolvidos no momento da exibição a partir do catálogo do canal. * **Resolução flexível do pedido** — envie `orderId` (UUID do Fire) **e/ou** `externalOrderId` (sua referência, casada em `metadata.order_id`); ao menos um é obrigatório, ambos vendor-scoped. Se os dois forem enviados e resolverem para pedidos **diferentes** → `409`. * **Não há `eventId` emitido pelo Fire para ecoar** — um status de agregador é um evento externo espontâneo (o Fire não é a fonte da verdade aqui). A idempotência é chaveada em `(channelCode, providerEventId)` + `status`; `channelCode` deve ser igual ao `metadata.channel.code` do pedido. * **Auth**: API key vendor-scoped com o novo escopo **`webhooks:aggregator`**. `202` async + fila, mesmo envelope que os callbacks fiscal / KDS. * Documentado em **EN / ES / PT**. ## 12 de junho de 2026 — Descontos do agregador em Injetar pedido Documentado como enviar descontos promocionais do agregador (iFood, Rappi, UberEats, etc.) no endpoint [Injetar pedido](/pt/api-reference/orders). * **Descontos do agregador são um método de pagamento, não uma linha de desconto.** Quando o agregador aplica um desconto ao cliente, o estabelecimento recebe o valor integral e o agregador reembolsa a diferença — modele como uma entrada extra em `payments.paymentMethods[]` com `paymentMethodCode: "AGGREGATOR_DISCOUNT"`, `transactionType: "BENEFIT"`, `processor` com o nome do agregador e `card: null`. * **`payments.discounts[]` fica vazio** para descontos do agregador — esse array é apenas para promos/cupons absorvidos pelo estabelecimento. * Nova regra de saldo documentada: `SUM(paymentMethods[].totalBill)` deve ser igual a produtos + cobranças extras + frete. * Novo [exemplo de request](/pt/api-reference/orders#descontos-do-agregador) com um pedido do iFood (BRL 38.69 CREDIT + BRL 1.00 AGGREGATOR\_DISCOUNT = BRL 39.69 bruto). * Atualizado em **EN / ES / PT**. ## 11 de junho de 2026 — Nomenclatura underscore + payload thin de fechamento de dia * **Nomes (breaking)** — `store.day-closed` → **`store.business_day_closed`** e `order.status-updated` → **`order.status_updated`** (nomenclatura underscore). Atualize seu switch de `event.type`. * **[`store.business_day_closed`](/pt/events/store-day-closed) agora é um payload thin** — identidade do fechamento (`businessDayId`, `businessDayDate`, `timezone`, `status`), timing (`openedAt`/`closedAt`), `closedBy` e uma **`store` mínima** (`uid`, `code`, `externalId`, `countryCode`, `timezone`, `currencyCode`). **Removido do evento**: `sales`, `metrics`, `summary`, `byChannel`, `byPaymentMethod`, `forceClosedOrders`, `closureStats`, `cancelledOrders`, `metadata` — consulte-os por `businessDayId` quando precisar. **`snapshotId` renomeado para `businessDayId`** (mesmo valor). * Documentado em **EN / ES / PT**. ## 10 de junho de 2026 — Eventos canônicos de pedido + evento de cozinha Os eventos fiscais perdem o país do nome e passam a ser **canônicos de pedido** — continua sendo o contrato **v1**, só muda o `event.type`: * **`fiscal.authorized.br` → [`order.invoiced`](/pt/events/order-invoiced)** e **`fiscal.cancelled.br` → [`order.reversed`](/pt/events/order-reversed)**. Se sua integração despacha por `event.type`, atualize o switch — a forma do payload não muda. * **Agora disparam para todos os países**: Brasil (SEFAZ via seu provedor fiscal) e CO/EC/CL/AR/VE via o [callback fiscal genérico](/pt/api-reference/fiscal-callback). O país viaja em `fiscal.countryCode`. * **Novo evento [`order.status_updated`](/pt/events/order-status-updated)** — o KDS avança o pedido na cozinha (`preparing` → `ready` → `dispatched`), com bloco `kitchen` e o percurso completo em `history`. * **O Fire é a fonte da verdade** — os webhooks de entrada ([callback fiscal](/pt/api-reference/fiscal-callback), [status KDS](/pt/api-reference/kds-order-status)) agora **validam que `eventId` referencia um evento emitido pelo Fire para esse pedido**; caso contrário respondem `400` antes do `202`. Sempre ecoe o `event.id` de um envelope que você recebeu. * Documentado em **EN / ES / PT**. ## 9 de junho de 2026 — Contrato de eventos **v1** O contrato de eventos de pedido/fiscal/fechamento agora é oficialmente **v1**. Todas as adições são **retrocompatíveis** (novos campos opcionais); o formato anterior é preservado como **v0 (descontinuado, histórico)** — alterne com o seletor de versão no topo de cada página de evento. * **Descontos** — descontos de pedido e de produto trafegam como objeto **`Discount`** (`priority`, `type` `FIXED`/`PERCENTAGE`, `value`, `net_price`, `discount_value`, `net_price_after_discount`) em `payments.discounts`, `payments.totals[].discounts` e `orderLines[].price.*[].discounts` + `lineTotals[].discounts`. * **Impostos granulares** — `taxes[]` agora carrega os impostos da reforma BR `IBS_UF`, `IBS_MUN`, `CBS` junto de `ICMS`/`PIS`/`COFINS`, com metadata de reforma (`cClassTrib`, `reducao`, `rateNominal`, `rateEffective`). O detalhamento é **uniforme em todos os países** — LATAM carrega seu `IVA` local no mesmo `taxes[]`; apenas a emissão SEFAZ (`metadata.fiscal`, `fiscal.*.br`) é exclusiva do BR. * **`itemType`** — enum completo: `PRODUCT` / `COMBO` / `MODIFIER` / `PACKAGING`. * **`fulfillment.delivery.deliveryConfirmationCode`** — código de confirmação do agregador (ex. iFood / Rappi). * **store.business\_day\_closed** — `sales` agora inclui `product_discounts`, `gross_before_discounts`, `shipping`, `extra_charges`, `total_charged` e `taxes_by_type`. *(Substituído em 11 de junho — esses agregados já não vão embutidos no evento; o payload de fechamento agora é thin. Veja a entrada no topo.)* * **order.cancelled / order.invoiced / order.reversed** — carregam o snapshot v1 do pedido. * Documentado em **EN / ES / PT** com exemplos atualizados. ## 8 de junho de 2026 * **menu.updated**: adicionado `productModifiers[n].overrides[]` — permite definir um preço diferente para uma opção específica de modificador quando pertence a um produto específico. Cada override aponta para um `productId` e fornece seu próprio `priceInfo.price` e `priceInfo.salePrice`. Atualizado EN/ES/PT. ## 5 de junho de 2026 * **menus.sync**: página removida — o Fire envia um único evento `menu.updated` por menu; a sincronização em lote não é mais um evento separado. * **menu.updated**: campo `event.timezone` removido do payload. Adicionado `data.groupId` — UUID que identifica o batch de sincronização; vários eventos emitidos juntos compartilham o mesmo valor, permitindo correlacioná-los em sistemas externos. Os arrays `schedules` de categorias e produtos agora incluem exemplos completos de 7 dias com janelas de horário diferentes por categoria (ex.: Hambúrgueres 11:00–23:00, Café da Manhã 07:00–11:00). Campo `standardTime` em produtos documentado: `true` herda os horários do menu, `false` significa que o produto tem seu próprio array `schedules`. Atualizado EN/ES/PT. * **Injetar pedido**: o campo `type` é agora **obrigatório** em cada item de `order.products[]`, em cada item de `selectedModifiers[]` e em cada item de `payments.extraCharges[]`. Valores aceitos: `COMBO` (produto com grupos de modificadores não vazios), `PRODUCT` (produto simples vendável ou opção vendável dentro de modificadores), `MODIFIER` (opção de modificador puro), `PACKAGING` (item de embalagem). Payloads que omitem `type` são inválidos. Exemplos de requisição atualizados em EN/ES/PT. * **Injetar pedido**: documentado `shippingMethod.delivery.additionalInfo.deliveryConfirmationCode` como string opcional para enviar o código de confirmação da entrega. ## 1 de junho de 2026 * **Injetar pedido**: seções **Valores e faixas de preço** e **Frete e descontos**; três exemplos de requisição conciliados (entrega simples, desconto na linha + frete, vários produtos + desconto do pedido); ênfase em `payments.shippingCost[]`, `payments.discounts[]` e `discountsValue` por produto (EN/ES/PT). ## 27 de maio de 2026 * **menus.sync**: exemplo de payload completo (categorias, produtos, grupos de modificadores, horários); `data.menus[]` substituído por `data.menu` (um cardápio por evento); páginas EN/ES/PT na webhook reference. * **menu.updated**: estrutura geral alinhada com `menus.sync` — campos do catálogo (`list`, `categories`, `products`, `modifierGroups`, `scheduledActivities`) aninhados em `data.menu`; tabelas de campos e exemplo de remoção atualizados. * Guia **Publicação de cardápio** (EN/ES/PT): exemplos e passos de processamento atualizados para `data.menu`. * **Injetar pedido**: campo opcional `comment` documentado em `order.products[]`; exemplo de requisição atualizado (substitui `productComment`). * **menu.updated** / **menus.sync**: os `productId` das opções de modificador devem existir em `products`; o exemplo inclui `prod_size_small` e `prod_size_large`. * **menu.updated**: indentação do exemplo principal do payload corrigida em `data.menu`. * **Webhooks de cardápio** (`menu.updated`, `menus.sync`, **product.updated**): `data.country` documentado e exemplificado como **ISO 3166-1 alpha-2** (ex.: `EC`, `BR`, `CO`) em vez de um ID numérico de país. ## 26 de maio de 2026 * Adicionada a aba **Manuais do usuário** como seção principal da navegação. * Adicionados manuais do FIRE POS V2 para **Vinculação**, **Caixas** e **Códigos de autorização** em inglês, espanhol e português. * Adicionadas imagens placeholder sutis para as capturas pendentes do POS, mantendo a estrutura visual final dos guias enquanto as capturas são preparadas. * **Injetar pedido**: removido o campo `order.stock` do corpo (não faz parte do contrato). Exemplo de resposta **200** atualizado para o envelope real (`data`, `isArray`, `status`, `method`, `pathname`, `duration`, `traceId`). * **Login** (playground): `authMethod: none`, URL absoluta de staging no frontmatter `api:`, cabeçalho `Content-Type` com valor padrão e `grant_type` padrão para evitar *Missing required fields* ao usar **Testar**. * **Injetar pedido**: `price` da linha de produto documentado com todos os campos da **faixa de preço** e `taxes[]` (`name`, `rate`, `amount`, `metadata` opcional). * **Injetar pedido**: `payments.shippingCost[]` e `payments.discounts[]` documentados como as mesmas linhas de faixa de preço que `totals[]`; exemplo de requisição atualizado com linhas de frete e desconto. * **Cancelar pedido**: referência da API atualizada para a rota de agregador `POST /api/v4/integrations/sales/aggregator/orders/{order_uid}/refund`, com campos de cancelamento/reembolso e envelope padrão de resposta; movida para baixo de **Injetar pedido** na referência da API. ## 11 de maio de 2026 * Nova aba **Alterações** no fim da navegação e esta página inicial. * Removida a página de **listagem de canais de venda** e o item correspondente na navegação (todos os idiomas). * **Introdução da API**: texto ajustado; card de canais de venda removido. * **Injetar pedido**: cabeçalho `Authorization` documentado (EN). **ES e PT**: caminho, cabeçalhos e corpo atualizados para o contrato atual de integração (objetos de canal/serviço, dispositivo, operador, exemplos). * **Login** (**ES** e **PT**): alinhado a `POST /api/authentication/login` e resposta `accessToken` (client credentials). * **Página inicial em espanhol** (`/es/`): conteúdo revisado. * **Configuração**: novo guia **Integrações de agregadores** (painel Fire: endpoints de webhook e eventos de teste).