Registro de alterações

​

21 de outubro de 2026 — Importar e exportar o catálogo

• Importar e exportar — manual novo. Dois formatos: Backup completo (JSON), com categorias, modificadores, listas de preços, produtos e menus, para guardar uma cópia ou levar o catálogo para outro ambiente; e Planilha editável (Excel), com categorias, produtos e preços em linhas simples, para alterar muitos de uma vez.
• Primeiro se revisa — importar nunca grava na hora: o arquivo é analisado, você revisa o que seria criado, atualizado e excluído, e só então o aplica. Antes de aplicar, o Fire guarda um backup dos dados atuais.
• Mesclar e Substituir — Mesclar cria e atualiza, e não exclui nada. Substituir deixa os dados exatamente como estão no arquivo e exclui o que não está nele; é reservado a administradores da plataforma, que também podem Desfazer uma importação aplicada.
• Combinações afetadas — o detalhe lista as combinações de loja × canal × Tipo de Fulfillment que usam um menu ou uma lista de preços que muda.

​

13 de outubro de 2026 — Guia de API keys e preços promocionais no backoffice

• API keys — as keys são criadas em Developers → API Management com Create API Key: você escolhe um nome, os scopes e uma expiração opcional. Selecione um vendor no dashboard antes de criar a key: com All vendors selecionado a key fica sem vínculo de vendor, e os endpoints que o exigem respondem 403.
• Scopes — todos os scopes do dashboard, com os endpoints que cada um libera, incluindo cash-management:write e kiosks:write.
• Gerenciar keys — você pode editar os scopes de uma key sem mudar o segredo dela; nome, descrição e expiração ficam fixos depois de criada, e não há rotação integrada (crie uma key nova, troque e depois revogue a antiga).
• Header — envie a key em x-api-key. Authorization: Bearer pk_live_... continua funcionando como alias legacy; se você enviar ambos, x-api-key vale.
• Listar menus e Obter menu agora apontam para o guia sobre o scope menu:read e o vínculo de vendor.

• Listas de preços — as promoções agora ficam aqui, ao lado do preço, e também valem dentro dos combos. Até onde uma promoção chega e por que um preço sugerido é só um preço riscado que nunca é cobrado.
• Menus — um menu não tem mais tipo de entrega próprio: ele usa o da linha de atribuição. Três lentes (dia, tipo de entrega, preços) e a nova aba Overrides.
• Atribuição de menus — os preços promocionais viajam com o Sync, os lotes caem de 50 para 20 linhas e as alterações de preço salvas na pré-visualização só chegam aos agregadores, não ao POS nem ao Quiosque.
• Grupos de modificadores — adicionar um grupo a um produto o copia: alterações posteriores no grupo não chegam aos produtos que já o têm. Perguntas diferentes por tipo de entrega.
• Produtos — combos não têm preço próprio: o cliente paga a soma das opções que escolhe. O preço de referência “a partir de”, as promoções dentro de um combo e os preços por tipo de entrega.

​

6 de outubro de 2026 — Novo endpoint: listar os terminais de uma loja

• GET /external/stores/{storeId}/terminals — retorna o type, o status e o lastSeenAt de cada terminal, e o seu externalId (em quiosques, o device ID da tela QR). Por padrão traz os terminais ativos e suspensos; os revogados são pedidos com status=REVOKED. Filtre por type e reduza a resposta com fields. Usa o scope store:read que você já tem para os endpoints de lojas.

​

5 de outubro de 2026 — O parcial do dia na impressão de cupom

• Só o dia aberto da loja; qualquer outra data responde 409 PRINT_DAY_NOT_OPEN.
• A resposta traz subject.partial: true, e freshness.asOf é o horário do corte.
• Sem partial, o endpoint se comporta igual a antes.

​

30 de setembro de 2026 — O bloco fiscal das lojas tem o mesmo formato em todos os países

• Colômbia: metadata traz claveTecnica, rangoFacturacion e rangoNotaCredito (as faixas da DIAN).
• Equador, Chile, Argentina, Venezuela: as três chaves aparecem, em null. Antes não vinham.
• Brasil: sem mudanças.

​

28 de setembro de 2026 — Endpoints de menus da External API documentados

• Listar menus — quais ternas (loja × canal × tipo de fulfillment) de uma loja têm hoje um menu gerado, sem o menu.
• Obter menu — o último menu gerado de uma terna, no mesmo formato de menu.updated, com um bloco sync que diz se chegou ao canal.

​

25 de setembro de 2026 — Dinheiro entregue e troco nos eventos do pedido

• customerCashAmount é um número e traz o valor real. Até 24 de setembro de 2026 trafegava sempre como o texto "0", inclusive em pagamentos em dinheiro. Agora é o dinheiro entregue pelo cliente: para uma conta de 22.9 paga com uma nota de 50, 50; 0 nos meios que não são dinheiro.
• changeAmount entra na referência — o troco entregue pelo caixa, como número: 27.1 no exemplo anterior, 0 nos meios que não são dinheiro, null quando o caixa não o enviou. Já trafegava nos eventos; faltava na referência.
• Se o seu consumidor validava que customerCashAmount fosse texto, agora falha. Leia como número. Os eventos de pedidos injetados antes de 24 de setembro continuam trazendo "0", então um reenvio de um pedido antigo também.

​

23 de setembro de 2026 — Manual do Agente de catálogo

• Agente de catálogo — como conversar ou enviar um arquivo para etiquetar produtos, quais decisões o agente pede (modo, termos novos, alias) e por que uma aprovação pode sair parcial quando alguém edita o produto nesse meio-tempo.

​

16 de setembro de 2026 — cStat volta a ser emitido, dentro de countryData

• Brasil: authority.countryData.cStat. O código com que o órgão resolveu este documento: 100 numa autorização, 135 num cancelamento. É vocabulário do órgão, então viaja ao lado de chaveAcesso e protocolo, não na raiz do bloco.
• O cancelamento leva o próprio código, não o da nota. O order.reversed traz 135 —o evento de cancelamento registrado na SEFAZ— enquanto o order.invoiced que o precedeu mantém 100. Verificado de ponta a ponta em staging.
• Viaja como o provedor envia, number ou string. Não normalizamos um tipo que o órgão não escolheu.
• Pelo callback fiscal já funcionava: tudo o que vai dentro de document e não é canônico chega a countryData sem alteração. Envie cStat ali e ele chega — não foi preciso mudar nada do seu lado.
• mensagemSefaz continua de fora. Volta apenas o código.
• As rejeições continuam sem emitir evento. Um documento rejected guarda seu código mas não dispara order.invoiced nem order.reversed, então nesse caso cStat não chega até você.

​

15 de setembro de 2026 — Impressão no envio do KDS, zoom e Agente Fire Android

• Impressão no envio — By screen ou By station, documentos e timing fiscal. Arme a fila na tela KDS. O dashboard avisa se a estação de impressão não tem tela ativa.
• Ações na tela — zoom de estação/ticket (toque duplo no temporizador, tecla Q). Se a impressora falhar com o fiscal pronto, o ticket mostra Queued: printer failed.
• Board do operador — Operator fiscal printer no PC do supervisor (não a fila da cozinha).
• Instalação no Android — APK no tablet do KDS. kds-agent.fire.rest deve resolver para 127.0.0.1. Token e nome da impressora devem coincidir com o fire-kds.
• Estações / Roteamento — o veto de item type na estação sumiu. As categorias vivem só na estratégia de roteamento.

​

15 de setembro de 2026 — Datas do cancelamento e rejeições

• O cancelamento mantém as datas da fatura. authority.issuedAt e authority.authorizedAt continuam como a fatura os tinha, mesmo que o callback cancelled envie os seus. Antes assumiam a hora do cancelamento enquanto compensates.issuedAt seguia apontando para a fatura, então o mesmo bloco contava duas histórias. Para saber quando o documento foi anulado, use authority.cancelledAt.
• Um resultado negativo não guarda dados de comprovante. Em rejected, denied e error, o Fire ignora documentNumber, providerDocId, issuedAt, authorizedAt, os valores, pdfUrl, xmlUrl e graphic mesmo que o provedor os envie; são guardados documentType, docSubtype, as chaves do país em document, failure, provider e metadata. Um documento rejeitado era lido como um autorizado, com número e com authorizedAt. Um documento que já tinha dados de comprovante os mantém.

​

15 de setembro de 2026 — Bloco fiscal estruturado e eventos fiscais novos

• Breaking — o bloco fiscal de order.invoiced, order.cancelled e order.reversed é estruturado. Os campos canônicos passam para authority (documentType, documentNumber, issuedAt, cancelledAt…), os valores para authority.amounts e os identificadores do órgão (chaveAcesso, claveAcceso, cufe, protocolo…) para authority.countryData. dataAutorizacao passa a ser authority.authorizedAt; docType, cStat e sefazCancellation não são mais emitidos. Cada caminho anterior tem exatamente um caminho novo: veja Mudanças de caminho.
• Breaking — num cancelamento o bloco passa de cancellation.metadata.fiscal para cancellation.fiscal, e cancellation.metadata não é mais emitido. Se o pedido não tinha documento autorizado, a chave fiscal não existe — antes vinha null, então uma comparação com === null deixa de bater.
• Breaking — o callback fiscal tirou todos os campos canônicos de document para a raiz (documentType, docSubtype, documentNumber, issuedAt, authorizedAt, cancelledAt, authorizationMode, providerDocId, totalAmount, taxAmount, currencyCode, pdfUrl, xmlUrl, graphic); document agora leva só os identificadores do país. Renomeações: countryCode → country, docType → documentType (SALE_INVOICE ou CREDIT_NOTE, os únicos dois aceitos), error → failure (com scope e details), providerSpecific → metadata, emittedAt → issuedAt. Um emissor com os nomes anteriores recebe 400 indicando o campo — no caso de docType, em authorized e cancelled. No Equador numeroAutorizacion é retirado: o identificador autorizado é claveAcceso. cnpjEmitente não faz parte do contrato.
• order.cancelled leva o bloco fiscal em todos os países com documento autorizado; antes era só o Brasil.
• history e compensates — order.invoiced e order.reversed levam cada parada do percurso do documento, da mais antiga à mais nova. compensates aponta para o documento que o vigente substitui: vem preenchido em order.reversed e null em order.invoiced.
• authority.providerIdentity e authority.providerMetadata — o provider e o metadata do callback agora chegam ao pedido e aos eventos, com os mesmos nomes da numeração fiscal. null quando não enviados; o PlugNotas (Brasil) nunca os envia.
• Como o fiscal funciona no Fire — os dois atos (numerar e autorizar), os dois blocos do pedido e os dois caminhos pelos quais um documento chega ao Fire.
• Do callback aos eventos — qual evento sai para cada callback e onde cai cada campo.

​

4 de setembro de 2026 — Cupons nas linhas do pedido

• orderLines[].rewardId — o código de resgate do cupom, ou null. Os modificadores selecionados também o levam: num combo o desconto costuma estar nos modificadores, não no contêiner. Há duas formas válidas e nenhuma é erro: null com desconto (uma remarcação de catálogo, sem cupom) e um código com discountValue: "0" (o cupom mudou o preço de tabela em vez de descontar).
• data.marketing.coupons[] — estava reservado para uso futuro; agora leva { rewardId, name, metadata } por cupom. metadata.scope é product, order ou shipping, e metadata.amount é o dinheiro que ele descontou. Um cupom com scope: "order" aparece apenas aqui: o seu valor chega às linhas já distribuído entre elas e nada liga as parcelas a ele.

​

3 de setembro de 2026 — Credenciais Fire do KDS, linhas de comandas e categorias de estação

• Credenciais Fire API — padrão da conta versus override por vendor. A base URL é só o host da Fire; o fire-kds acrescenta as rotas de print e cancel.
• Categorias de estação — códigos usados como item_type no roteamento, mais miniaturas de produto na visualização da categoria.
• Credenciais Fire do KDS (técnico) — linha de vendor → padrão da conta → env. Print lê só FISCAL_PRINT_*. Cancel pode cair em FIRE_*.
• Ações na tela — Linhas de comandas (1–3) reservam espaço para notas. Se a Fire rejeitar um cancel, o operador vê a rejeição e o detalhe de policy; o trabalho fica falho.

​

3 de setembro de 2026 — O catálogo: produtos, categorias e grupos de modificadores

• Produtos — os quatro tipos, os interruptores que decidem se algo vende, o preço, os modificadores, os combos e as sugestões.
• Categorias — os blocos com que o cliente percorre o cardápio, o horário deles e a exclusividade de canal.
• Grupos de modificadores — as perguntas feitas na hora do pedido, e as opções que as respondem.
• As opções de um modificador são produtos do catálogo. Para oferecer queijo extra tem que existir um produto queijo extra; o preço dele é lido daquele produto, nunca digitado no grupo.
• Num grupo só se definem dois números: mínimo e máximo. Obrigatório/opcional e única/múltipla são deduzidos deles, então um grupo não pode se contradizer.
• A exclusividade de canal é herdada. Marcar uma categoria como exclusiva a tira do Golden Menu junto com os produtos dela.
• Um combo não tem aba de preço, e o preço que a lista mostra é uma referência calculada, não o que você cobra. O preço real sai da lista de preços do destino.

​

3 de setembro de 2026 — Menus: montar o cardápio e fazê-lo chegar ao canal

• Menus — Golden e custom, a herança, o diálogo de criação, as abas Structure e Overrides, e as lentes de preço e de dia.
• Atribuição de menus — a matriz loja x canal x fulfillment, a atribuição em massa, o Sync e seus avisos, e a pré-visualização.
• O tipo de fulfillment é escolhido uma vez e não pode ser alterado. É o único campo do menu sem volta: errar significa criar o menu de novo.
• Salvar um menu não o publica — no editor não há botão de publicar. O menu chega a um canal só quando alguém sincroniza a linha correspondente na tela de atribuições.
• O Sync achata o menu fresco, sem versionamento. Envia o menu e a lista de preços exatamente como estão salvos naquele segundo; não é possível republicar um estado anterior.
• Uma linha pode ficar em Synced e ainda assim ter perdido produtos. Um produto sem preço na lista atribuída fica fora do envio em vez de ser publicado em zero, e a única coisa que avisa é o chip de avisos.

​

2 de setembro de 2026 — Em falta: desligar produtos durante a operação

• Em falta — a caixa de diálogo de desligamento, o alcance por canal, o motivo obrigatório, a restauração e a aba de auditoria.
• Um desligamento nunca sobrevive ao fechamento da loja. O teto é o fim da jornada operacional, não uma quantidade fixa de horas: um produto desligado hoje amanhece vendendo.
• O alcance é um par de canal e tipo de entrega. Um produto pode ficar desligado no quiosque e continuar sendo vendido no caixa.
• Como opção de um combo, o produto continua selecionável. Se ele também é vendido dentro de grupos de modificadores, a caixa de diálogo os nomeia e o desligamento os registra, mas o que os canais recebem é disponibilidade por produto: uma opção não tem onde entrar ali.
• O motivo é obrigatório e não é editável. Alterar a validade move apenas o horário — o motivo fica como o registro do porquê o produto foi desligado.
• Publicar o cardápio encerra o desligamento, mas só se cobriu todo o seu alcance. Um desligamento de toda a loja sobrevive a uma publicação que chegou a um canal, porque nos outros o produto continua fora de venda de verdade. O desfecho é Substituído por um sync.
• O desligamento fica salvo mesmo que o canal não fique sabendo. Avisar é informado separado de salvar, e os desligamentos cujo aviso não chegou são contados no cabeçalho e marcados na sua linha.

​

15 de agosto de 2026 — O bloco fiscal: identificadores por país, cancelamento e provedor

• 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.

​

13 de agosto de 2026 — A numeração fiscal agora viaja em todos os eventos do pedido

• 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, order.completed, order.invoiced e order.cancelled.

​

11 de agosto de 2026 — BOH API: qty_base derivado no servidor com item_unit_id

​

11 de agosto de 2026 — BOH API: resolução de estabelecimento por ID fiscal em pedidos de compra (Fase 19)

• 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.

​

11 de agosto de 2026 — BOH API reestruturada: uma página por endpoint

​

11 de agosto de 2026 — BOH API: ordens de compra — resolução por supplier_sku e external_user_id

​

10 de agosto de 2026 — Manuais KDS: emparelhamento, board do operador, riscar linhas e defaults de display

​

7 de agosto de 2026 — BOH API: operações, identidade, sincronização em massa e endpoints de compras

• 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.

• 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.

​

7 de agosto de 2026 — Manuais BOH: linhas por canal, contagens colaborativas, moeda da conta

• 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.

​

7 de agosto de 2026 — Listas de preços: novo manual do usuário

• 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.

​

6 de agosto de 2026 — Batimentos de saúde de quiosques, KDS e caixas

• Saúde de componentes — 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.

​

4 de agosto de 2026 — Novo campo assignedAt em eventos de menu 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. Não viaja em product.price_updated nem em product.availability_changed — esses eventos transmitem apenas seu delta.
• menu.updated / 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.

​

4 de agosto de 2026 — Assinatura por e-mail do registro de alterações

• 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.

​

2 de agosto de 2026 — order.opened e os blocos de pagamento diferido

• Novo evento 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.

​

22 de julho de 2026 — Manuais do usuário BOH

• Visão geral e conceitos — como catálogo, receitas, abastecimento, movimentos, contagens e relatórios se relacionam; o fluxo de estoque; mapa do menu BOH.
• Lojas e fornecedores — lojas BOH vinculadas ao Restaurant OS e fornecedores com vínculos item–fornecedor (preço, unidade de compra, SKU).
• Catálogo — grupos de unidade e unidades, itens, etiquetas de itens intercambiáveis (FIFO / FEFO / prioridade / maior estoque), classificações.
• Receitas — receitas de venda, produção e subreceitas; ciclo rascunho → publicada → arquivada; linhas por canal; simulador de venda.
• Abastecimento — programações de recebimento, ciclo de vida dos pedidos de compra, níveis par e pedido sugerido.
• Recebimentos e devoluções — recebimentos de mercadoria (entrada de estoque, vínculo ao pedido de compra, sobre-recebimento) e devoluções ao fornecedor.
• Perdas e consumos internos — catálogo de motivos de perda, eventos de perda, consumos internos.
• Transferências e produção — transferências entre lojas e lotes de produção com rendimento.
• Contagens — áreas de inventário, contagens completas/parciais e o app móvel de contagem.
• Relatórios — usos e consumos, perdas, rendimento de produção e saldo em uma data.

​

13 de julho de 2026 — Cancelar pedido: campo cancellationType

​

3 de julho de 2026 — Injetar pedido: distribuição de desconto em combo

• 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

​

29 de junho de 2026 — Manuais do usuário KDS

• Visão geral e conceitos — 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 — aplicar um modelo (assistente de blueprint) ou configurar do zero; ordem recomendada das etapas.
• Estações — campos, regras opcionais por canal / serviço / tipo de item, criação passo a passo.
• Telas — identificador de dispositivo, criar e atribuir estações, relação tela ↔ estação.
• Roteamento — 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 — 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 — avançar, reter/liberar, desfazer, cancelar, paginação, menu de configurações e atalhos de teclado.
• Tela de espera — tela para clientes (áreas em preparo / pronto, destaque ao ficar pronto, paginação automática).

​

22 de junho de 2026 — Novo guia: Estrutura de produtos · Publicação de cardápios atualizada

​

Novo guia: Estrutura de produtos

• 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.

​

15 de junho de 2026 — order.completed — novos campos do método de pagamento

• 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.

​

15 de junho de 2026 — Campos de detalhe do método de pagamento

• 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.

​

14 de junho de 2026 — Webhook de status de pedido do agregador

• Novo webhook de entrada POST /v1/webhooks/aggregators/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

• 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 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 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

• fiscal.authorized.br → order.invoiced e fiscal.cancelled.br → 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. O país viaja em fiscal.countryCode.
• Novo evento 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, status KDS) 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

• 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).