WhatsApp Error 135000: Generic User Error or Pacing Drop

What does WhatsApp error 135000 mean?

WhatsApp error 135000 means one of two things, and Meta documents them on two different pages that never mention each other. On the error-codes page it is a request the Cloud API could not process; on the business portfolio pacing page it is the code stamped on every held campaign message Meta decided not to deliver.

Here are the two descriptions side by side, exactly as Meta publishes them:

The first sentence is the whole of the details column for 135000 on Meta's WhatsApp error codes page. The second comes from Meta's business portfolio pacing page, which is dated "Updated: May 21, 2026". The error-codes row does not contain the word pacing, and the pacing page does not mention request parameters. A developer who looks the code up in the obvious place reads about syntax, and a business whose campaign died halfway reads nothing there about the portfolio review that follows.

Neither page says the two meanings are exclusive, and this piece will not pretend to know more than Meta wrote. What can be checked is where the code arrived, what the send response said first, and what Meta told your portfolio admins. Those three facts narrow it down quickly.

• What does WhatsApp error 135000 mean?
• Why does Meta's error page call 135000 a request-parameter error?
• How does business portfolio pacing turn a campaign into 135000 failures?
• Which business portfolios does portfolio pacing apply to?
• Is business portfolio pacing the same as template pacing?
• How do you tell which 135000 you have?
• Why is "delete and recreate the template" the wrong fix for a pacing drop?
• Should you resend messages that failed with 135000?
• Does Direct Send get paced and dropped with 135000 too?
• How should a campaign be built so a pacing drop is caught early?
• What does Meta not tell you about error 135000?

Why does Meta's error page call 135000 a request-parameter error?

Because on that page 135000 sits in the "Other errors" table as a catch-all for a send request Meta could not complete. The full row reads:

"Message failed to send because of an unknown error with your request parameters." (Meta, WhatsApp error codes)

and the remedy beside it:

"See the endpoint’s reference to determine if you are querying the endpoint using the correct syntax. Contact customer support if you continue receiving this error code in response." (Meta, WhatsApp error codes)

Note the phrase "in response". This reading describes a refusal you get back from the send call itself. Developers have posted that response on Meta's own community forum, and it looks like this, with the trace id shortened:

{
  "error": {
    "message": "(#135000) Generic user error",
    "type": "OAuthException",
    "code": 135000,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "Generic user error"
    },
    "fbtrace_id": "A7O_..."
  }
}

That body was posted by a developer, not by Meta, in a question on Meta's developer community forum whose timestamp reads 27 August 2024, more than a year before Meta's changelog added business portfolio pacing on 8 December 2025. So 135000 was a synchronous refusal long before it was a pacing outcome.

The words "Generic user error" appear nowhere on Meta's current error-codes page. That does not matter much, because Meta tells you not to build on titles anyway: "Meta recommends that you do not rely on titles for your error handling logic as titles will eventually be deprecated." (Meta, WhatsApp error codes). Match on the integer.

How does business portfolio pacing turn a campaign into 135000 failures?

Business portfolio pacing releases a large template send in batches, watches recipient feedback between batches, and drops whatever is still held if that feedback looks suspicious. Meta defines it as "a template message delivery batching mechanism that allows time to gather feedback on any template sent as part of a large-scale messaging campaign." (Meta, business portfolio pacing)

The sequence, in Meta's words, once you "attempt to send a large number of templates within a short period of time using any of your portfolio’s business phone numbers":

1. "an initial set of messages will be processed normally"
2. "subsequent messages will be held, and the message_status property in API responses will be set to held_for_quality_assessment"
3. "We will then deliver messages in batches, monitoring feedback before releasing each new batch."
4. "If feedback suggests suspicious activity, all remaining held messages will be dropped", each one producing a failed status webhook with code 135000.

Two things follow that a recipient-by-recipient view hides. The failures are not random across the list: they are the messages still held when Meta stopped releasing batches, which in a campaign sent in list order is the later part of the list. And expect them as a cluster: Meta describes one decision to drop "all remaining held messages", with a failed webhook "for each dropped message", not a series of separate refusals.

Meta also says who hears about it: "Portfolio admins will be informed of dropped messages by Meta Business Suite notification, WhatsApp Manager banner, and email." (Meta, business portfolio pacing). If your developers see 135000 and nobody with admin access to the business portfolio has seen one of those three notices, ask them before you touch the code. The same mechanism appears briefly in what actually caps a WhatsApp broadcast, as one of several ceilings on a large send.

Which business portfolios does portfolio pacing apply to?

Two kinds, by Meta's own list, and the first is a volume threshold rather than a judgement about you. Meta says business portfolio pacing applies to:

"business portfolios that have sent less than 500K template messages collectively, across all of their business phone numbers, within a moving 365-day lookback period" (Meta, business portfolio pacing)

and to:

"business portfolios that are currently being monitored for suspicious activity (for example, for violating our WhatsApp Business Messaging Policy or WhatsApp Messaging Guidelines)" (Meta, business portfolio pacing)

To put Meta's figure in daily terms, which is my arithmetic and not a number Meta publishes: 500,000 template messages spread evenly over 365 days is about 1,370 a day (500,000 ÷ 365 ≈ 1,369.9). A newly onboarded business portfolio has sent none, so every new one begins under the threshold. In India, a Diwali or year-end campaign from a portfolio that otherwise sends little is the kind of "large number of templates within a short period of time" the page describes, although Meta gives no figure for what counts as large.

Two scoping details matter. The count is collective "across all of their business phone numbers", so a second or third number does not reset anything. And Meta qualifies the whole feature at the top of the page: "This feature is being released gradually over the coming weeks so may not apply to you immediately." That sentence was still there when I read the page on 16 and 17 October 2026, ten months after the changelog entry that introduced the feature. Being under 500K makes a portfolio eligible for pacing. It does not prove pacing is switched on for it.

Is business portfolio pacing the same as template pacing?

No, and Meta says so on the pacing page itself: "Note that business portfolio pacing is different from template pacing, which only affects marketing and utility templates." (Meta, business portfolio pacing)

The difference shows up in the code you get when held messages are dropped. Template pacing judges one template; when its feedback is bad, Meta says "Each held message will be dropped and trigger a messages webhook with "status":"failed" and "code":"132015" (Cloud API users)." (Meta, template pacing). Business portfolio pacing judges the campaign and the business portfolio behind it, and its drops carry 135000.

A template paused this way then follows the escalating pause rules described in every status a WhatsApp template can be in. Both mechanisms use the same held_for_quality_assessment value on the send response, so that value alone does not tell you which one is holding your messages. The drop code does. Template pacing, its three entry routes and its seven-day utility window are covered in why an approved template can be accepted and still not arrive.

How do you tell which 135000 you have?

Start with where the code arrived: in the HTTP response to your send, or on a failed status webhook after Meta had already handed you a message id. Meta's error page says errors in general can take either route, or both: "Cloud API errors are returned either synchronously as a Graph API response, asynchronously via Webhook, or sometimes through both methods" (Meta, WhatsApp error codes), so the route is a strong clue rather than a proof. Combine it with the other signals.

A pacing drop reaches you in the documented shape of a failed status webhook (Meta, status messages webhook reference). Meta publishes the shape but no example title or details text for this particular drop, so the strings below are placeholders, the fragment is trimmed to the statuses array, and your handler should key on code:

{
  "statuses": [
    {
      "id": "wamid.<MESSAGE_ID>",
      "status": "failed",
      "timestamp": "<UNIX_TIMESTAMP>",
      "recipient_id": "<USER_PHONE_NUMBER>",
      "errors": [
        {
          "code": 135000,
          "title": "<ERROR_TITLE>",
          "message": "<ERROR_MESSAGE>",
          "error_data": { "details": "<ERROR_DETAILS>" }
        }
      ]
    }
  ]
}

One awkward detail about the earlier send response. Meta's template pacing page says "Cloud API will always include a message_status property" with accepted or held_for_quality_assessment, while its send-messages reference says "The message_status property is only included in responses when sending a template message that uses a template that is being paced." (Meta, send messages). Store the field whenever it is present and treat its absence as no information, not as proof the message was never held.

Why is "delete and recreate the template" the wrong fix for a pacing drop?

Because a pacing drop is a judgement about the business portfolio, and the template is not what Meta is reviewing. The recreate advice comes from vendor help pages and forum replies; Meta's pacing page points the other way:

"In addition, the business portfolio will be prevented from sending or creating templates while it undergoes further review." (Meta, business portfolio pacing)

So during the review the portfolio cannot create the replacement template in the first place. Once it can, the replacement starts life without a quality history, and Meta lists "Newly created templates" among those "potentially subject to pacing" (Meta, template pacing). A fresh template is not a clean slate.

The other common advice, removing and re-adding the phone number, fails for the same reason. Pacing is measured "across all of their business phone numbers" and triggered by sends "using any of your portfolio’s business phone numbers", so every number in the portfolio shares the review.

For a synchronous 135000 the template can genuinely be involved, since a request carries the template name, language and parameters. Even then the fix Meta names is syntax against the endpoint reference, not deletion. Change one thing at a time against a request that works, and keep each failure's fbtrace_id, which Meta describes as a "Trace ID you can include when contacting Direct Support. The ID may help debug the error." (Meta, WhatsApp error codes)

Should you resend messages that failed with 135000?

No for a pacing drop, and only after changing the request for a synchronous one. Meta dropped those held messages because feedback on the campaign looked suspicious, and it has said the portfolio will be prevented from sending templates during the review. A resend loop at that point produces more failures at best.

Meta does not say that resending counts against a portfolio, so I will not claim it. What it does say is how the review can end: "If messaging activity has been found to violate our policies or guidelines, it may be fully disabled. Portfolio admins will be notified of any enforcement actions and will have the option to appeal any decisions." (Meta, business portfolio pacing). A portfolio under review is a poor moment to add volume. Wait for the outcome, read whatever enforcement notice reaches the portfolio admins, and decide then. If the outcome is a restriction, what a restriction is and how to request a review covers the appeal route Meta says you will be offered.

Meta publishes no length for the review and no list of what it checks. While you wait, the health status endpoint is a documented place where account-level blocks appear as data. A request of GET /<NODE_ID>?fields=health_status on a phone number, WhatsApp Business Account (WABA) or template returns a can_send_message value for the app, the business portfolio and the WABA, plus the number or template you asked about, where "BLOCKED: Indicates that the node does not meet one or more messaging or calling requirements." (Meta, health status). Meta does not say what that field reports during a pacing review, so I cannot tell you it will show BLOCKED. It is still worth checking before the next campaign rather than after, because Meta describes the summary as indicating whether "you will be prevented from messaging and calling entirely."

For a synchronous 135000, a resend of the identical request will usually fail the same way. One Meta FAQ explains why repeat attempts can still surprise you: "Cloud API validates each message request through multiple checks. If any check fails, the message send will not succeed. For reasons of system efficiency and overall health, the order in which these checks are performed may change. As a result, you might receive different error codes for the same API request, depending on which validation fails first." (Meta, WhatsApp support). A different code on the retry is not progress. It may be the same broken request failing a different check.

WabaCRM's own send queue treats 135000 as final for the message it was returned for and does not retry it, for the same reason.

Does Direct Send get paced and dropped with 135000 too?

Yes, since 15 October 2026. Meta's changelog entry for that date reads: "Added Message pacing to Direct Send: Direct Send messages are subject to business portfolio pacing, and pacing outcomes are reported through status messages webhooks." (Meta, WhatsApp changelog)

Direct Send is Meta's route for utility messages, and authentication messages in beta, without pre-built templates: "Instead of pre-creating and managing message templates, you send business-initiated messages directly and Meta auto-generates the matching templates behind the scenes." (Meta, Direct Send). Meta says business portfolios "with a messaging limit of 100,000 or unlimited are generally eligible" for its utility messaging.

The Direct Send limits page states how its pacing surfaces, and the wording differs from the template route in one way that matters:

"Direct Send messages are subject to business portfolio pacing. A paced message may be held and delivered later, or dropped. These outcomes are reported only through status messages webhooks: a dropped message triggers a webhook with status set to failed and error code 135000." (Meta, Direct Send features and limits)

"Only through status messages webhooks" means the early warning that template sends get, held_for_quality_assessment on the send response, is not promised for Direct Send. If you send utility messages that way, the 135000 webhook may be the first sign of pacing you see.

How should a campaign be built so a pacing drop is caught early?

Record per-recipient outcomes by error code, read the send response's pacing field, and stop sending the moment 135000 appears in a burst. Each step follows from what Meta documents:

• Store message_status from every send response. A run of held_for_quality_assessment values is your warning that batches are being released on feedback.
• Store every failed status webhook with its code, per recipient. A pacing drop shows up as a cluster of 135000 on the last part of a campaign, and a single campaign-level failure count hides that shape.
• Pause the rest of the campaign on the first cluster. Meta has already said the portfolio cannot send templates during the review.
• Send to your most engaged contacts first. Pacing releases batches on feedback, and the people who expect your message are the least likely to report it.
• Split very large sends across days rather than numbers. The trigger is a large number of templates in a short time, counted across every number in the portfolio.

A per-recipient report is what makes the shape visible after the fact. In WabaCRM the campaign report lists each recipient with a status and a detail line, and groups the campaign's failures by Meta's error code, so a run of one code stands out from scattered individual failures.

What does Meta not tell you about error 135000?

More than it tells you, and each gap is worth knowing before you plan around this code. Meta does not publish:

• A rule for telling the two meanings apart. The arrival route is strong evidence, not a documented guarantee.
• The title or details text of a pacing drop. Only the code and the failed status are documented.
• What counts as "a large number of templates within a short period of time". No figure, no window.
• How long the review lasts, or what it examines beyond its policies and guidelines.
• Whether the gradual rollout has reached your portfolio. The "coming weeks" sentence gives no date and no way to check.

Read each 135000 against its route, its timing and the notices your portfolio admins received, and treat any page that gives a single cause and a single fix, this one included, with suspicion until you have checked those three things.

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