Variáveis enviadas no webhook (referência completa)

Quando um gatilho dispara na loja, o plugin manda um POST JSON pra URL do webhook configurada na mensagem (na Rishi). Esse artigo descreve a estrutura completa do payload — útil pra entender o que tá disponível pra usar nos placeholders do template Meta, e essencial se você for debugar algo no painel da Rishi.

Anatomia do payload

A requisição é:

• Método: POST
• Content-Type: application/json
• Timeout: 10s
• Body: JSON com 4 blocos de chaves mergeados num único objeto

{
  // BLOCO 1 — Placeholders do gatilho (varia por tipo de evento)
  "first_name": "Maria",
  "order_id": 10231,
  "order_total": "199.90",
  "products_list_inline": "Camiseta, Caneca",
  // ... outros placeholders

  // BLOCO 2 — Metadados do pedido (só quando o gatilho carrega WC_Order)
  "id": 10231,
  "status": "wc-processing",
  "currency": "BRL",
  "total_amount": "199.90",
  "billing_email": "maria@exemplo.com",
  "_payment_method": "pix",
  "_billing_first_name": "Maria",
  // ... TUDO de wp_wc_orders e wp_wc_orders_meta

  // BLOCO 3 — Identificação do disparo
  "trigger": "woocommerce_payment_complete",

  // BLOCO 4 — Snapshot da mensagem cadastrada
  "db_message": {
    "message_id": 42,
    "hook": "woocommerce_payment_complete",
    "message_name": "Pagamento aprovado",
    "status": 1,
    "custom_settings": { "webhook_url": "https://...", "remote_message_id": 8 }
  }
}

Bloco 1 — Placeholders do gatilho

São os campos prontos pra usar como variável no template Meta. A lista varia por tipo de gatilho:

• Gatilhos de pedido (pago, novo, status alterado, atualizado, avaliado): first_name, last_name, order_id, order_number, order_total, products_list_inline, payment_method, tracking_code, coupon_codes, address — entre dezenas de outros. Veja Variáveis de gatilhos de pedido pra a lista completa.
• Gatilho de carrinho abandonado CartFlows: first_name, last_name, email, checkout_url, coupon_code, cart_total etc. Veja Variáveis do gatilho Carrinho abandonado (CartFlows).
• Gatilhos de lembrete de boleto, estoque, rastreio, licença: cada um tem placeholders próprios — documentados nos artigos específicos.

As chaves do payload chegam sem o {{ }} — no template você usa {{first_name}}, no JSON aparece "first_name".

Tratamento especial de valores monetários

Pra gatilhos de pedido, o plugin envia os valores no payload sempre crus (sem formatação de moeda):

• "order_total": "199.90" — valor cru retornado por $order->get_total().
• "order_items_subtotal_row", "shipping_cost_row", "discounts_total_row" — versão crua dos campos correspondentes.

As versões com R$ e separadores ({{order_total}} formatado, {{order_items_subtotal}}, {{shipping_cost}}, {{discounts_total}}) não chegam no webhook — elas são removidas antes do envio. Isso é proposital: a formatação cabe ao template da Meta ou ao processamento na Rishi.

checkout_token derivado de checkout_url

Sempre que o payload tem uma chave checkout_url, o plugin automaticamente injeta uma chave extra checkout_token com o querystring do URL (a parte após o ?). Útil quando você quer remontar a URL com um domínio diferente.

Exemplo:

"checkout_url": "https://loja.com/checkout/?wcf_ac_token=ABC123",
"checkout_token": "?wcf_ac_token=ABC123"

Bloco 2 — Metadados do pedido (importante)

Sempre que o gatilho carrega um WC_Order, o plugin despeja no payload tudo o que existe sobre aquele pedido no banco:

1. Linha completa de wp_wc_orders (HPOS) — id, status, type, currency, tax_amount, total_amount, customer_id, billing_email, date_created_gmt, date_updated_gmt, parent_order_id, payment_method, payment_method_title, transaction_id, ip_address, user_agent, customer_note, date_completed_gmt, date_paid_gmt.

2. Todas as linhas de wp_wc_orders_meta — meta keys padrão do WooCommerce (_billing_first_name, _billing_phone, _shipping_address_1, _order_key, etc.) e meta keys custom de qualquer plugin que tenha gravado algo no pedido (CartFlows, AutomateWoo, gateway custom, tracking, license manager, plugins de fidelização).

3. Todas as linhas de wp_postmeta correspondentes ao order_id — só pra ambientes em modo de compatibilidade legacy (antes do HPOS).

Os três conjuntos são mergeados — em caso de conflito de chave, wp_wc_orders_meta vence sobre postmeta.

Como saber quais chaves de meta existem

A forma mais fácil é abrir um pedido recente em WooCommerce → Pedidos, e a aba WhatsApp mostra uma seção Metadados do pedido com o print_r completo do array que vai pro webhook. Use isso pra descobrir nomes exatos antes de configurar na Rishi.

Bloco 3 — trigger

Uma string identificando qual gatilho exato disparou. Exemplos:

• woocommerce_payment_complete
• woocommerce_order_status_changed
• cartflows_email_42 (carrinho abandonado, template ID 42)
• wc_boleto_reminder
• automation_for_whatsapp_tracking_correios

Útil na Rishi se você tem uma única URL de webhook tratando múltiplos gatilhos: o campo trigger te diz qual é qual.

Bloco 4 — db_message

Snapshot da linha da tabela local de mensagens — útil pra Rishi confirmar identidade da mensagem que disparou (especialmente o remote_message_id, que é o ID na Rishi).

Estrutura:

"db_message": {
  "message_id": 42,
  "hook": "...",
  "message_name": "...",
  "status": 1,
  "receiver": "owner|customer|fixed",
  "hook_params": { "delay": 0, "status": [...], "gateway": [...] },
  "custom_settings": {
    "webhook_url": "https://...",
    "remote_message_id": 8
  }
}

O custom_settings chega já decodificado como objeto (não como string JSON), facilitando o consumo do lado da Rishi.

Headers

Nenhum header de assinatura/HMAC é enviado. O webhook é um POST JSON simples — quem recebe deve validar pelo webhook_url ser secreto (a Rishi gera um URL único por mensagem, e a chave secreta vive no path/querystring).

Próximos passos

• Variáveis de gatilhos de pedido — referência específica dos campos que vêm em pedidos.
• Variáveis do gatilho Carrinho abandonado (CartFlows) — referência específica desse gatilho.
• Botões de URL e o modificador relative_url — como usar campos do payload em botões de URL do template Meta.