Feature request — button/component parameters in template sends (Pix payment button, Brazil)

Hi Zernio team,

We integrate with your API to send WhatsApp charge notices (rent and receivables) to customers in Brazil, and we've hit a limitation we can't work around on our side.

Context

Our messages are cold outreach: they almost never fall inside the 24-hour service window, so every send is an approved template that opens a new conversation via:

POST /v1/inbox/conversations
{
  "accountId":        "<connected WhatsApp account>",
  "participantId":    "<phone>",
  "templateName":     "<approved template>",
  "templateLanguage": "pt_BR",
  "templateParams":   ["...", "..."]
}

That works fine for text-only templates.

The limitation

We have an approved template that carries a payment button with a Pix dynamic code (Brazil's instant-payment scheme). On WhatsApp, a button like this is a separate template component: its parameter is addressed by component type, sub-type and button index — it is not a body placeholder.

templateParams is a flat array of strings, and as far as we can tell it only maps to body placeholders ({{1}}, {{2}}, …). There is no field in the request to supply a parameter for a button component, so the send is rejected — in our case with Required template parameter is missing. Appending the Pix code as one more element of templateParams doesn't help either: it's consumed as a body variable, and the button still has no value. [ paste here the exact error / message id from your most recent attempt, if it differs ]

The practical effect is that any approved template with a parameterized button (payment, copy-code, dynamic URL) can't be sent through the API today.

What we're asking for

Option A (preferred, generic): component-aware template parameters. An optional field alongside templateParams that lets us address non-body components explicitly, e.g.:

"templateComponents": [
  { "type": "body",   "parameters": ["150,75"] },
  { "type": "button", "subType": "payment_request", "index": 0,
    "parameters": ["00020126580014BR.GOV.BCB.PIX..."] }
]

This would also cover copy_code (coupon-style copyable codes, which is how many Brazilian senders deliver a Pix "copia e cola") and url buttons with a dynamic suffix — one change, three use cases. Keeping templateParams working unchanged as the body-only shorthand would make it fully backwards compatible for existing integrations.

Option B (narrower): native Pix payment support. If a generic component API is out of scope, first-class support for Brazil payments — sending an order/payment message carrying a Pix dynamic code, with the resulting payment status delivered through the existing webhook — would solve our case specifically.

Happy to help

We can share the approved template definition, request/response pairs and message ids for failed attempts, and we're glad to test any preview/beta endpoint against a real account.

Is a change like this something you'd consider, and is there a rough timeline we could plan around?

Thanks,

Gefferson Ferraz