order.completed dispara quando um pedido é injetado com sucesso e está pago. Carrega o snapshot V4 do pedido como trigger.data — todos os campos que seu flow precisa para agir sobre o pedido sem voltar a chamar o Fire.
Condição de disparo
O Fire emiteorder.completed exatamente uma vez por pedido, na primeira vez em que ambos são verdadeiros no momento de injeção:
order.status === "COMPLETED"order.paymentStatus === "SUCCEEDED"
PENDING de pagamento, ou que falham o pagamento, nunca produzem order.completed. Cancelamentos após completar produzem um evento separado order.cancelled — eles não retraem order.completed.
O que tem em trigger.data
trigger.data é o snapshot V4 do pedido — o mesmo objeto que está persistido em flow_queue.trigger_data e exposto aos templates do seu flow.
As chaves top-level, em ordem:
Exemplo — payload real de produção (BR, sanitizado)
O exemplo abaixo vem de uma linha real deflow_queue.trigger_data (tenant sandbox brasileiro, canal KIOSK, serviço dine-in). Os campos PII são substituídos por placeholders; o restante dos campos e formatos é verbatim.
Os valores monetários são strings com o valor inteiro escalado ×10.000 (
"229000" são 22,9 BRL, não 229.000). Isso evita drift de ponto flutuante através de múltiplas integrações. Parseie com uma biblioteca decimal, nunca com parseFloat. A exceção é paymentMethods[].totalBill, que a origem às vezes envia como número JSON — trate ambos.Referência de campos
Identificadores top-level
string
UUID interno do pedido no Fire. Estável através de entregas; use junto com
event.id para rastreabilidade.string | null
Código curto legível mostrado em recibos e telas KDS (ex.:
95K, OC-br-001). null quando o canal não atribui um.string
Dia de negócio ao qual este pedido pertence, em
YYYY-MM-DD. Calculado em hora local da loja, então um pedido feito às 01:00 pode pertencer ao dia de negócio anterior dependendo do corte de fim de dia.string
O ID de pedido tal como provido pelo canal/agregador na injeção. Use para reconciliar com sistemas upstream (POS, dashboards de agregador).
string | null
Timestamp ISO 8601 UTC de quando o pedido foi originalmente feito. Distinto de
event.createdAt, que é quando a execução do flow começou.string
Sempre
"COMPLETED" para este evento.string
Sempre
"SUCCEEDED" para este evento.boolean
true se pontos de fidelidade foram resgatados neste pedido.boolean
true se o cliente acumulou pontos de fidelidade.boolean
true se algum desconto foi aplicado.string
Nota free-text do cliente para o pedido inteiro. Empty string quando não definido.
data.store
object
Snapshot da loja no momento em que o pedido foi completado.
data.client
object | null
Cliente que fez o pedido.
null para pedidos de canal totalmente anônimos. Para pedidos BR de “consumidor final”, client é populado com valores placeholder (govIdType: "FINAL_CONSUMER", govIdNumber: "00000000000").data.payments
object
Detalhamento de dinheiro.
data.fulfillment
object
Como o pedido é entregue.
data.kds
object
Contexto do kitchen display.
data.device e data.operator
object
{ uid, name, platform, metadata.ip } — dispositivo de origem. Os campos podem ser null para canais não físicos.object
{ uid, name, session.uid } — staff/caixa que processou o pedido. Todos os campos null para canais self-service (quiosque, web).data.orderLines
object[]
Produtos pedidos. Totalmente camelCase (transformado pelo builder V4).
data.marketing, data.metadata, data.channel
object | null
Loyalty + cupons.
null na maioria dos países hoje; reservado para uso futuro.object
Bag free-form para extras a nível de pedido. Frequentemente
{}.object
{ uid, code, metadata }. Exemplos de code: KIOSK, APP, IFOOD, RAPPI.Dados fiscais
Os dados fiscais são incluídos apenas quando a loja tem emissão fiscal habilitada (
store.storeFiscalConfig.enabled === true). Para países sem fiscal ou lojas sem configuração, todas as três localizações abaixo estão ausentes ou em null.order.completed carrega informação fiscal em três localizações distintas. Cada uma serve um propósito diferente:
1. data.store.storeFiscalConfig — identidade do emissor e config do provedor
Identifica a entidade legal que emite o documento e como autenticar com o provedor fiscal. Credenciais NÃO estão aqui intencionalmente — o nó fiscal as busca por provedor/account.
2. data.payments.metadata.fiscal — agregados fiscais a nível de pedido
Totais agregados estilo SEFAZ, prontos para envio ao provedor fiscal (seu provedor fiscal no Brasil). Os valores são strings × 10000.
3. data.orderLines[n].metadata.fiscal — classificação fiscal por linha
Códigos fiscais por produto. Usados pelo provedor fiscal para classificar cada linha no documento.
taxes[n].metadata (em payments.totals[].taxes[], orderLines[].price.totalPrice[].taxes[] e orderLines[].lineTotals[].taxes[]) com códigos como cst, cBenef, cClassTrib, reducao, rateNominal, rateEffective.
Variações por país
O exemplo acima é de uma loja brasileira com emissão fiscal habilitada — o caso mais complexo. O formato V4 é idêntico em todos os países; o que muda é quanto dado fiscal está populado. Hoje apenas o Brasil carrega os agregados por imposto / por linha (payments.metadata.fiscal, orderLines[n].metadata.fiscal, lineTotals[n].taxes[]). Outros países têm esses blocos presentes mas null / vazios.
- Brasil (BR)
- Argentina (AR)
- Chile (CL)
- Colombia (CO)
- Ecuador (EC)
- Venezuela (VE)
As lojas brasileiras com
storeFiscalConfig.enabled === true carregam o payload fiscal completo — veja a seção Dados fiscais acima. Marcadores de país:store.locationInfo.country.code: "BR"·name: "Brasil"·timezone: "America/Sao_Paulo"store.locationInfo.currencyCode: "BRL"store.storeFiscalConfig.govIdType: "CNPJ"(14 dígitos)store.storeFiscalConfig.secondaryGovIdType: "INSCRICAO_ESTADUAL"payments.totals[].currency_code: "BRL",paymentMethods[].currencyCode: "BRL",orderLines[].selectedCurrency: "BRL"- Populados:
payments.metadata.fiscal(vBC / vNF / vICMS / vPIS / vCOFINS / vTotTrib …),orderLines[].metadata.fiscal(ncm / cfop / csosn),lineTotals[].taxes[](ICMS, PIS, COFINS, IBS_*)
Tabela de referência rápida
À medida que mais países tiverem um pipeline fiscal dedicado, seus eventos fiscais chegarão como
fiscal.*.{cc} (ex.: fiscal.authorized.co, fiscal.authorized.ec). Até lá, apenas order.completed e order.cancelled disparam para lojas não-BR — os blocos fiscais permanecem null / vazios.Handler de exemplo
Erros comuns
- Decimais como strings × 10000.
payments.totals[0].total === "229000"significa 22.9 BRL. Use uma biblioteca decimal; nunca comparseFloat. - O casing é misto em
payments.totals[]e partes depaymentMethods[]. Leia tantocurrencyCodequantocurrency_codedefensivamente. O builder V4 transforma a maior parte do snapshot mas passa os objetos de payment sem alteração. fulfillment.deliverypode estar presente mesmo para serviços non-delivery com zeros placeholder. Sempre ramifique emfulfillment.service.code.clientpode ser um placeholder “FINAL_CONSUMER” populado em BR — não énull. TrategovIdType === "FINAL_CONSUMER"como anônimo para analítica.event.idé o ID de execução do flow, não o ID do pedido. Useevent.idpara idempotência (muda por entrega), eorderIdcomo chave de negócio.- Routing multi-tenant. Use
store.account.uid,store.vendor.uidestore.codepara rotear ao tenant correto no seu sistema, mesmo que o Fire já dê escopo ao flow do lado dele.
Eventos relacionados
order.cancelled
Dispara quando este pedido é cancelado depois.
order.invoiced
Apenas Brasil — dispara quando a SEFAZ autoriza o documento fiscal do pedido.

