Registro de alterações

​

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