Skip to main content
Descontinuado (v0). Contrato anterior, mantido apenas como referência histórica. A versão atual é order.completed — v1.1.
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 emite order.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"
Pedidos que ainda estão 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 de flow_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.
Além disso, metadata por imposto vive dentro de cada 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.
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 com parseFloat.
  • O casing é misto em payments.totals[] e partes de paymentMethods[]. Leia tanto currencyCode quanto currency_code defensivamente. O builder V4 transforma a maior parte do snapshot mas passa os objetos de payment sem alteração.
  • fulfillment.delivery pode estar presente mesmo para serviços non-delivery com zeros placeholder. Sempre ramifique em fulfillment.service.code.
  • client pode ser um placeholder “FINAL_CONSUMER” populado em BR — não é null. Trate govIdType === "FINAL_CONSUMER" como anônimo para analítica.
  • event.id é o ID de execução do flow, não o ID do pedido. Use event.id para idempotência (muda por entrega), e orderId como chave de negócio.
  • Routing multi-tenant. Use store.account.uid, store.vendor.uid e store.code para 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.