Error 131008 is the most literal error in the WhatsApp Cloud API, and the fastest to fix once you read the right field. Meta documents it as "Required parameter is missing," with details stating the request is missing a required parameter, an HTTP status of 400, and a recommended action of consulting the endpoint's reference to determine which parameters are required (Meta for Developers, WhatsApp error codes reference, retrieved 2026-08-20).
The reason it costs teams time anyway is that most integrations log error.message and discard the nested error_data object, where Meta usually names the missing field. Fix that logging gap and 131008 becomes a five-second read rather than a debugging session.
This guide covers what is mandatory per message type, why the same request can pass in testing and fail in production, and the validation layer that removes the error class. For the wider failure surface, our WhatsApp Business API error codes reference indexes the rest.
Read error_data First
The generic response tells you little:
{
"error": {
"message": "(#131008) Required parameter is missing",
"type": "OAuthException",
"code": 131008,
"fbtrace_id": "AbCdEfGhIjK"
}
}The useful response carries error_data, and Meta populates it more often than most teams realise:
{
"error": {
"message": "(#131008) Required parameter is missing",
"type": "OAuthException",
"code": 131008,
"error_data": {
"messaging_product": "whatsapp",
"details": "The parameter messaging_product is required."
},
"fbtrace_id": "AbCdEfGhIjK"
}
}Log the whole error object rather than the top-level string. This is the same logging gap that makes error 100 look undebuggable, and closing it once fixes both.
What Is Required, by Message Type
Every send needs these three:
Field | Value | Notes |
|---|---|---|
|
| Required on every send, no exceptions |
| Recipient in E.164, digits only | No plus sign, spaces, or hyphens |
| The message type | Must match the object you supply |
Then, depending on type:
Type | Also required |
|---|---|
|
|
|
|
| The media object with either |
|
|
|
|
The template row is where 131008 overlaps with its neighbours, and telling them apart saves time:
- Missing the
componentsarray entirely, ortemplate.name→ 131008 componentspresent but the parameter count is wrong → error 132000- Count right but a value is malformed → error 132012
- Template name and language cannot be resolved → error 132001
Why messaging_product Dominates
This one field accounts for a disproportionate share of real 131008 traffic, for a reason worth understanding rather than just memorising.
messaging_product is a constant. Its value is always "whatsapp". It carries no information specific to the message, which makes it read like ceremony rather than data — and so it gets omitted when someone hand-builds a payload, writes a new send path, or refactors a request builder.
{
"messaging_product": "whatsapp",
"to": "919876543210",
"type": "text",
"text": { "body": "Your order has shipped." }
}Set it as a constant inside your request builder rather than as an argument callers must remember to pass. A field that cannot be forgotten is better than a field everyone remembers ninety-eight percent of the time. Our guide to WhatsApp API integration covers structuring the send layer around this.
Why It Passes in Testing and Fails in Production
The signature of most production 131008s is a payload builder with branches, where the common path is well tested and a rare branch is not.
Typical shapes this takes:
Conditional media attachment. The path that attaches an image sets the media object; the path for messages without an image sets type to something media-shaped but omits the object.
Optional personalisation. A branch that skips a template component when a customer record lacks a field, dropping a required components entry rather than supplying a default.
A new message type added later. Someone adds interactive messages to a builder written for text, and the new branch omits interactive.type.
Serialisation dropping nulls. A serialiser configured to omit null fields removes a required key whose value happened to be null, which is also a frequent cause of error 132012.
The diagnostic that separates these from a systemic problem: does 131008 affect every send of a given type, or only a subset? Every send points at the builder for that type. A subset points at a conditional branch, and the failing records will share whatever condition triggers it.
Removing the Error Class
Three practices, in order of value.
Validate against a schema per message type, in your own code. Define what each type requires and check the assembled payload before it leaves your service. The payoff is not just catching the error — it is getting an error message that names your field in your logs, instead of an opaque 400 from Meta's edge.
Build payloads per type rather than assembling one superset object. A single object with optional keys for every message type will eventually be sent with the wrong combination. Separate builders make the required set explicit.
Treat 131008 as non-retryable. The same payload fails identically every time, so route it to a dead-letter queue with the full error object and the record identifier, alert on volume, and fix the builder. Retrying at scale adds rate limit pressure to a defect you already have. This is the opposite of the correct handling for error 131000, which is a genuine 500 and should be retried — which is exactly why one blanket retry policy across all codes causes trouble.
One reassurance worth passing to the business: because the request was rejected at validation with a 400, no message was created and nothing was billed under the per-message pricing Meta adopted on 1 July 2025 (Meta for Developers, Pricing, retrieved 2026-08-20). Nor does it touch your quality rating. The cost is undelivered messages, not spend or standing.
Frequently Asked Questions
What does WhatsApp error 131008 mean?
Meta documents it as "Required parameter is missing," with details stating the request is missing a required parameter, returned with HTTP status 400. A mandatory field was absent from your send. The recommended action is to check the endpoint reference for which parameters are required, but reading error_data.details in the response is faster, since Meta usually names the missing field there.
Which parameters are required for a WhatsApp message send?
Every send needs messaging_product set to "whatsapp", to in E.164 format with digits only, and type. Beyond that it depends on the type: text.body for text, template.name and template.language.code plus a components array for templates, a media object with id or link for media messages, and interactive.type with its action object for interactive messages.
Why is messaging_product so often missing?
Because its value is always the same string and it carries no message-specific information, so it reads as boilerplate rather than as a parameter. It gets dropped when someone hand-builds a payload or writes a new send path. Setting it as a constant inside your request builder, rather than as an argument callers pass, removes the possibility.
Should I retry a request that returned 131008?
No. The failure is deterministic — an unchanged payload will be rejected identically every time. Send it to a dead-letter queue with the full error object and record identifier, alert on volume, and fix the payload builder. Retry logic belongs on genuine 500-class failures such as error 131000.
What is the difference between error 131008 and error 132000?
131008 means a required field was missing from the request — for a template send, typically template.name, the language code, or the components array itself. Error 132000 means the components were present but the number of variable parameters did not match what the template defines. One is an absent field; the other is a count mismatch.
Validate in Your Code, Not at Meta's Edge
Error 131008 has no interesting causes, which is what makes it worth engineering away entirely rather than debugging repeatedly. Meta tells you the missing field in error_data.details; most pipelines throw that away and then wonder why the error is opaque.
Two changes end it. Log the full error object so the diagnosis is instant. Then validate assembled payloads against a per-type schema in your own service, so a missing field surfaces as a named error in your logs at build time rather than as a 400 after a network round trip.
Prefer a messaging layer that validates before it sends? Helo.ai is a Meta Partner and Google RCS Anchor Partner of the Year, exposing a validated send interface over the Cloud API so malformed payloads fail in your stack rather than at Meta's edge. Talk to an expert.
Next: error 131009 if the field is present but its value is rejected, or error 100 for the broader request-shape failures.
