WhatsApp Error 132000 With the Right Number of Parameters

Why does WhatsApp error 132000 fire when my parameter count is correct?

Because on a template created with parameter_format set to named, 132000 is not counting your array. It is counting the values it could match to a declared parameter, and a value whose name matches nothing is not counted as supplied at all. An array of exactly the right length therefore comes back as a count mismatch, and the error text mentions only numbers, which is why the count is the first thing everybody re-checks and the last thing that turns out to be wrong.

Meta's own description of the code is the sentence every vendor helpdesk repeats:

"The number of variable parameter values included in the request did not match the number of variable parameters defined in the template." (Meta — WhatsApp Cloud API error codes)

The remedy underneath it is the more useful half, and almost nobody quotes it:

"See our Templates document to learn about parameters and make sure the request includes values for all of the parameters required by the template." (Meta — WhatsApp Cloud API error codes)

That does not say count the parameters. It says include values for all of the parameters required by the template, and on a named template a value is only for a parameter when its name matches one. The reason this is so easy to miss is that the same concept is spelled three different ways across the two API calls involved, and Meta's documentation nowhere flags the change.

• Why does WhatsApp error 132000 fire when my parameter count is correct?
• What do the four template payloads look like side by side?
• Why is the field param_name on create and parameter_name on send?
• What string does the Cloud API actually return for 132000?
• Is your template named or positional if you never set parameter_format?
• Which of 132000, 132012 and 132001 does each mistake produce?
• Why can 132018 never appear in your Cloud API logs?
• What breaks when a text header takes a named parameter?
• Can you mix named and positional parameters in one send?
• How do you tell a real count error from a name mismatch?

What do the four template payloads look like side by side?

No competing page puts these next to each other, which is a large part of why the failure is hard to reason about. There are four payloads in play, not two: a template is created one way and sent another, and each of those has a named form and a positional form. All four are Meta's own examples, reproduced from the template fundamentals page.

Creating a positional template:

{
  "name": "order_confirmation",
  "language": "en_US",
  "category": "utility",
  "parameter_format": "positional",
  "components": [
    {
      "type": "body",
      "text": "Hi {{1}}! Your order number is {{2}}. Thank you.",
      "example": { "body_text": [["Pablo", "860198-230332"]] }
    }
  ]
}

Creating a named template:

{
  "name": "order_confirmation",
  "language": "en_US",
  "category": "utility",
  "parameter_format": "named",
  "components": [
    {
      "type": "body",
      "text": "Thank you, {{first_name}}! Your order number is {{order_number}}.",
      "example": {
        "body_text_named_params": [
          { "param_name": "first_name", "example": "Pablo" },
          { "param_name": "order_number", "example": "860198-230332" }
        ]
      }
    }
  ]
}

Sending against the positional one:

"components": [
  {
    "type": "body",
    "parameters": [
      { "type": "text", "text": "Jessica" },
      { "type": "text", "text": "SKBUP2-4CPIG9" }
    ]
  }
]

Sending against the named one:

"components": [
  {
    "type": "body",
    "parameters": [
      { "type": "text", "parameter_name": "first_name", "text": "Jessica" },
      { "type": "text", "parameter_name": "order_number", "text": "SKBUP2-4CPIG9" }
    ]
  }
]

Both send payloads carry two objects in parameters. Both templates declare two variables. Count them and they agree, every time, in all four combinations. The only thing that distinguishes a working named send from a failing one is whether each parameter_name matches a param_name that was declared at creation, and nothing about the count will ever tell you that it did not.

Why is the field param_name on create and parameter_name on send?

This is the single most likely cause of a correct-looking count producing 132000, and it is a naming inconsistency rather than a rule. The same concept carries a different key on each side of the integration, and the keys are close enough to read past.

Checked against Meta's documentation on 11 September 2026.

Three spellings, and a fourth wrinkle underneath them: the positional creation payload does not use either key. It uses body_text, an array inside an array, with no names anywhere. So a codebase that grew a named-template path on top of an existing positional one is carrying two creation shapes and two send shapes, and a helper that builds parameters without threading the name through produces an array of exactly the right length with every name missing.

Meta sets out the declaration rule itself clearly enough:

"Upon template creation, if a string includes one or more parameters, you can specify their format — either named or positional — and you must include an example value for each parameter." (Meta — Template fundamentals)

What it does not do anywhere on that page is point out that the field you use to give the example is not the field you use to give the value.

What string does the Cloud API actually return for 132000?

Not the one in the documentation. Meta's error reference describes the code in a full sentence about variable parameter values; the API answers with something much shorter. A public Chatwoot bug report, filed against a header named parameter failure, reproduces the response:

"(#132000) Number of parameters does not match the expected number of params" (chatwoot issue #13851)

That matters practically. If you built an alert by matching on Meta's documented wording, "the number of variable parameter values included in the request did not match", it is unlikely to fire. The one publicly captured response for this code reads differently from the documentation, and the runtime string says "params" where the documentation says "parameters". Match on the numeric code instead. The documentation prose and the runtime prose are maintained separately and can drift apart without anything breaking on Meta's side.

Is your template named or positional if you never set parameter_format?

Positional. Meta is explicit about the default:

"If you do not specify a format, the template uses positional format by default." (Meta — Template fundamentals)

Nothing about a creation payload that omits parameter_format looks wrong, and nothing rejects word-shaped placeholders in the body text of a template that is positional underneath. So a template whose body literally reads Thank you, {{first_name}}! can be a positional template with an unusual placeholder name, and a send payload that carefully supplies parameter_name: "first_name" has nothing to match against. The template looks named to every human who reads it and is not named to the API.

Meta's rules for what each format's placeholders may contain are worth having side by side when you are trying to tell which one you are looking at:

"Parameters using the named format must be unique, single strings, composed of lowercase characters and underscores, wrapped in double curly brackets, for example, {{first_name}}." (Meta — Template fundamentals)

"Positional parameters must be ordered array index numbers, starting from 1, wrapped in double curly brackets: ({{1}}...{{2}}...and so on)." (Meta — Template fundamentals)

Read those together and the asymmetry is clear: {{1}} can only ever be positional, but {{first_name}} is legal-looking in a positional template too, because the placeholder text is not what decides.

Most management screens, including WabaCRM's own templates list, show a variable count on the row. That count is exactly the figure a 132000 sends you to verify, and it will always look right, because the count genuinely is right. The field that would actually settle the question is parameter_format, which is a property of the template as Meta stored it rather than something a table column usually surfaces — much like the fourteen underlying statuses behind a three-state badge, covered in every status a WhatsApp template can be in.

Which of 132000, 132012 and 132001 does each mistake produce?

Three codes cluster around template sending and they answer three different questions. Getting the wrong one in your head sends you to the wrong fix.

Checked against Meta's documentation on 11 September 2026.

The distinction between the first three rows is where most of the wasted time goes. 132012 is a shape complaint, and Meta describes it as:

"The variable parameter values included in the request are not using the format specified in the template." (Meta — WhatsApp Cloud API error codes)

So a currency or date parameter supplied as a bare string, or a parameter object missing the type its component expects, lands on 132012. A parameter that simply could not be matched to anything lands on 132000, because from the template's side of the check nothing was supplied for that variable. Two of the four rows above hand you the identical code from unrelated causes, which is the whole reason this page exists.

If the code you are seeing is none of these and the send is accepted but nothing arrives, that is a different problem entirely and has its own causes — see template approved, messages accepted, nothing arriving.

Why can 132018 never appear in your Cloud API logs?

Because it is not a Cloud API error code. It appears on the same reference page as 132000, a few sections lower, under the heading for the Marketing Messages API for WhatsApp. Meta lists its message as:

"(#132018) Template validation error" (Meta — WhatsApp Cloud API error codes)

with the detail line:

"There's an issue with the parameters in your template." (Meta — WhatsApp Cloud API error codes)

and a remedy of "Review the errors, update the parameters as needed, and resend your message using a correctly configured template." It carries an explicit HTTP status of 400 Bad Request, which neither 132000 nor 132012 does.

The two tables are not even the same shape, which is the quickest way to see that they describe different surfaces. The table 132018 sits in has five columns: Code, Message, Details, Possible reasons and solutions, and HTTP status code. The table holding 132000 and 132012 has three: Code, details, and possible reasons and solutions. No message string and no HTTP status is published for either of them, so there is nothing to match on but the number.

A striking number of vendor error lists file 132018 next to 132000 as though they were siblings on the same surface, which produces two wrong beliefs at once. The first is that an ordinary template send can return it, so people search their logs for a code that cannot be there. The second is that because 132018 is documented as a 400, the other two must be as well. Neither follows. If you are sending through the Marketing Messages API for WhatsApp, then 132018 is genuinely yours to handle; if you are posting to the Cloud API's messages endpoint, it is not.

The detail sentence is also commonly reproduced as though it were the error's message. It is not. It sits in the Details column, and the message is the shorter "Template validation error" string above.

What breaks when a text header takes a named parameter?

Headers are where this bites hardest in practice, for two compounding reasons. The first is a hard limit:

"Text headers support 1 parameter." (Meta — Template components)

with the header text itself capped at "Maximum 60 characters." The second is that a header's named example uses a third key again — header_text_named_params, not body_text_named_params — so a builder that handles body parameters correctly and reuses the body key for the header produces a template whose header declares nothing.

"example": {
  "header_text_named_params": [
    { "param_name": "sale_start_date", "example": "December 1st" }
  ]
}

At send time the header component then wants its own parameters array with its own parameter_name inside it, and a send that populates the body correctly while leaving the header's name unmatched produces 132000 with no indication of which component was short. The Chatwoot report quoted earlier is the blunt version of the same thing, a required header named parameter with an empty parameters object, and it is worth reading for the response string it captures rather than as an instance of the correct-count case.

The practical implication is to check components in this order when a 132000 arrives on a template that has a header: header first, body second, buttons third. The body is where everyone looks, and the header is where a single-parameter limit and a third field name meet.

Can you mix named and positional parameters in one send?

Meta documents no rule either way, and it is worth being precise about that rather than repeating what vendor pages assert. parameter_format is declared once per template, as a single value, so at the template level there is no mixing to do — a template is one or the other. What is genuinely undocumented is the send-side case: what happens when a parameters array carries parameter_name on some objects and omits it on others.

Meta publishes no sentence forbidding it and no worked example showing it. Several third-party pages state a hard prohibition; none of them cite a Meta source for it. On this site a negative claim gets checked as hard as a positive one, so the honest position is that Meta has not published a rule here, and the safe engineering position is to build the array uniformly from the template's declared format rather than relying on undefined behaviour to be forgiving.

That is also the cheapest defence against the whole class of failure. If the code that builds a send payload reads parameter_format off the template and branches once, the naming cannot drift. Any platform sitting between you and the WhatsApp Business Platform makes this choice on your behalf, and it is a fair thing to ask about before you standardise on one.

How do you tell a real count error from a name mismatch?

Given that both produce the identical code and the identical string, checking in a fixed order beats reading the message again.

1. Read the template back and look at parameter_format, not at the body text. Word-shaped placeholders prove nothing, because positional is the default when the field is omitted. This is the check that resolves the majority of correct-count 132000s.
2. If it is positional, delete every parameter_name from the send payload. A positional template has no names to match, and supplying them is the mirror image of the same mistake.
3. If it is named, compare the set of parameter_name values against the set of param_name values declared at creation — as sets, not as a count, and remembering that named values may legitimately arrive in any order.
4. Check the header separately. One parameter maximum, its own header_text_named_params key, and no hint in the error about which component fell short.
5. Only then count. A genuine count mismatch is real and does happen, but it is the case that the error message already describes accurately, which makes it the least likely one to have escaped your first look.

Running this in reverse — starting from the count, because the error mentions the count — is the slow path, and it is the path the error text pushes you onto. That is the whole of the trap: 132000's wording is accurate about its own check and silent about what feeds it.

Every Meta quotation on this page was read from Meta's own documentation on 11 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.