WhatsApp Error 132012: Template Parameter Format Mismatch

WhatsApp error 132012 means template variable values are formatted incorrectly (e.g. header expected IMAGE, received UNKNOWN). Causes, fixes, and prevention.

TL;DR: WhatsApp error 132012 means the variable parameter values in your send request do not match the format defined in the approved template. Meta's details string is "Variable parameter values formatted incorrectly." The most common real-world variant is a media header that expects an image but receives an unrecognized value (header: Format mismatch, expected IMAGE, received UNKNOWN). Fix it by aligning every component's parameter type and value with the approved template.

What Error 132012 Means

Error 132012 is a template send error. It fires when the structure or type of the parameters you pass at send time does not match the structure of the template as approved in WhatsApp Manager. Meta's official details value is:

"Variable parameter values formatted incorrectly."

In practice the API often returns a more specific runtime message inside error_data.details. A widely reported example (community-observed, not the canonical Meta string) — captured verbatim on Microsoft Q&A for Azure Communication Services — is: (#132012) Parameter format does not match format in the created template. header: Format mismatch, expected IMAGE, received UNKNOWN. This appears when a template was created with an image header but the send payload omits a properly typed image header object.

Where You See It

132012 is a synchronous error. It is returned immediately in the Graph API HTTP response (typically 400 Bad Request) when you POST to the /messages endpoint. The message is rejected before it is accepted for delivery, so you will not see it in a statuses[].errors[] status webhook — there is no message ID to report a status against. If your request returned 200 and the message later failed, you are looking at a different error, not 132012.

Common Causes

  • The template has a media header (image, video, document) but the send payload sends no header component, or sends it with the wrong type, producing expected IMAGE, received UNKNOWN.
  • A media header is passed but the link URL is unreachable, not publicly accessible, or returns a non-media MIME type, so Meta cannot resolve it to the expected media type.
  • A parameter that should be a typed object (e.g. {"type":"image","image":{"link":"..."}}) is sent as a plain text string.
  • Button parameters (URL button suffix, copy-code/coupon button, flow button) are passed in the wrong shape or omitted.
  • Named vs. positional parameter mismatch: the template was created with named parameters but the payload uses positional {{1}}-style values, or vice versa.
  • Currency, date-time, or other typed body parameters are sent as raw strings instead of the structured object Meta expects.

How to Fix It

  1. Open the template in WhatsApp Manager and note every component: header type (text/image/video/document), body variables, and each button.
  2. For a media header, send a properly typed header component, e.g. {"type":"header","parameters":[{"type":"image","image":{"link":"https://example.com/image.jpg"}}]}. Confirm the URL is publicly reachable and returns a supported MIME type.
  3. Match each body parameter's type to what the template expects. Per Meta's Templates "Parameter formats" docs, templates default to positional format unless you defined named parameters; named parameters must be unique, lowercase, underscore-only strings wrapped in double curly braces, e.g. {{first_name}}.
  4. Send button parameters in the exact shape required for the button type (URL suffix, coupon code, or flow action payload).
  5. Test by sending the template from WhatsApp Manager / API to a test number; if it sends there but not from your code, the defect is in your payload construction.

How to Prevent It

  • Build the send payload programmatically from the template definition you fetch via the Message Template API, rather than hand-coding parameter arrays per template.
  • Validate that every media link is public and returns the correct Content-Type before sending.
  • Keep a regression test that sends each production template to a sandbox number after any template edit, since editing a template can change its component structure.
  • Decide on named or positional parameters at template creation and keep your sender consistent with that choice.

Related Errors

FAQ

Q: What does "format mismatch, expected IMAGE, received UNKNOWN" mean? A: Your template has an image header, but your send payload did not include a correctly typed image header object (or the media URL could not be resolved). Add a header component with a type: image parameter and a reachable link.

Q: Is 132012 the same as 132000? A: No. 132012 is a format/type mismatch; 132000 is a count mismatch (the number of values doesn't equal the number of variables in the template).

Q: Why does my template work in WhatsApp Manager but fail with 132012 from the API? A: Manager builds a correct payload for you. From the API you must construct the component objects yourself; the mismatch is in your payload, not the template.

Q: Does 132012 ever arrive via webhook? A: No — it is rejected synchronously in the API response. You will not get a status webhook for a message that was never accepted.

How Dualhook Helps

Honest answer: error 132012 happens in your own sending backend, because it is your code that builds the template payload and calls Meta's /messages endpoint. Dualhook is not in the message-send path and never reads or stores message content, so it cannot rewrite or fix your parameter arrays. Where Dualhook helps is around the edges: it surfaces your approved templates and their component structure via its advanced whatsapp_business_management access (see Templates and Sending Template Messages), so you can confirm what header/body/button shapes a template actually expects before you build the payload. Log the full Graph error metadata (code, error_data.details, fbtrace_id) in your sender.

Browse more docsStart Free Trial