WhatsApp Flows Error 132068 and 132069: Blocked or Throttled

Why does Meta say my Flow is in blocked or throttled state?

Because an automatic monitor watched your Flow's endpoint, decided it was unhealthy, and changed the Flow's status without asking anyone. No human reviewed your content, no policy was breached, and there is nothing to appeal — the only thing that lifts either state is the endpoint becoming healthy again.

The two send-time errors read exactly like this:

132068  Flow is in blocked state.

132069  Flow is in throttled state and 10 messages using this
        flow were already sent in the last hour.

Both strings are Meta's own (Meta - WhatsApp Flows error codes). Both codes also appear in the Cloud API's general error table, where the entire remedy column for each one reads:

"Correct the Flow" (Meta - WhatsApp Cloud API error codes)

That is the whole of the published guidance in the place most people look. The code names a state. It never names the metric that put the Flow into that state, or the number that metric crossed, or when. The threshold and the metric are named in exactly one place, and they very probably arrived there several times before any send started failing.

• Why does Meta say my Flow is in blocked or throttled state?
• Which Flows can be blocked or throttled at all?
• Which metric tripped, and at what threshold?
• Can an endpoint that returns no errors still be throttled?
• What does a throttled Flow actually stop you doing?
• How do you read the alert that arrived first?
• Why does a handler built from Meta's docs never match?
• What do 421, 432 and 427 mean coming back from your endpoint?
• Is cannot_be_served a different problem?
• How does a Flow get back to Published?
• What should you check first when 132069 appears in a campaign?

Which Flows can be blocked or throttled at all?

Not all of them. Meta scopes the entire mechanism in one sentence:

"Flow health and monitoring is only applicable to Flows that use data from your endpoint." (Meta - Flow Health and Monitoring)

A Flow whose screens are static, or that only navigates from one screen to the next without calling a server you operate, has no endpoint to monitor. No latency to measure, no error rate to compute, no availability to drop. It cannot enter either state.

So the first thing either code tells you is that a request is leaving Meta and arriving at a server on your side, and that server is the subject of the incident. Not the Flow JSON, not the template that carried it, not your number's quality rating.

It is also the distinction to hold onto when comparing tools. A multi-step conversation built and run inside a platform is a different thing from a WhatsApp Flow backed by your own endpoint; the first gives Meta's monitor nothing to watch.

Which metric tripped, and at what threshold?

Meta's Flows webhooks guide publishes four alert events, each with its own threshold ladder and its own detection window. This table almost never surfaces in a search for either error code, and it is the part of the documentation that actually diagnoses them.

The alert messages Meta ships in its own sample payloads name the same figures in prose. For the endpoint error rate:

"The flow endpoint request error rate has reached the 10% threshold in the last 30 minutes. A higher error rate will make it harder for users to complete the flow, resulting in drop-offs." (Meta - Flows Webhooks)

And the availability sample payload's message reads:

"The flow endpoint availability has breached the 90% threshold in the last 10 minutes. Users will be unable to open or use the flow." (Meta - Flows Webhooks)

The page's own prose adds that the alert is two-sided: "You receive a notification when the endpoint availability goes below the 90% threshold and then again when it goes above the threshold." (Meta - Flows Webhooks) So recovery is announced on the same field as the breach.

The windows are short — ten minutes for availability — so an incident that clears before anyone notices it can still have moved the Flow's status. And three of the four ladders have three rungs, which is what makes the warning sequence real rather than theoretical.

Can an endpoint that returns no errors still be throttled?

Yes, and this is the likeliest cause of an unexplained 132069.

Meta's own definition of an endpoint timeout is generous:

"Endpoint request has timed out. It took more than 10 seconds to process the endpoint request." (Meta - WhatsApp Flows error codes)

Ten seconds. But the first p90 latency alert fires at one second, and Meta's remediation advice on the webhooks page is blunter still:

"Improve responsiveness of your endpoint and aim to return response in less than 1 second." (Meta - Flows Webhooks)

An endpoint answering every request correctly in three seconds is therefore throwing zero errors, returning zero timeouts and showing 100% availability — and is already past the first latency threshold, heading for the second. The 10× gap between "not an error yet" and "already generating alerts" is where this failure lives, and staring at exception counts will never surface it, because there are no exceptions.

If your endpoint calls a third-party CRM, a stock lookup or a payment gateway inside the request, that dependency's p90 is your p90.

What does a throttled Flow actually stop you doing?

Less than most descriptions suggest, which is exactly why it is confusing to diagnose. Meta's status definition is careful:

"Monitoring detected that the endpoint is unhealthy and set the status to Throttled. Flows with throttled status can be opened, however only 10 messages of the Flow could be sent per hour. You need to fix the endpoint to get it back to the PUBLISHED state." (Meta - Flows API)

The health guide says the same thing from the customer's side:

"Consumers will still be able to open previously received Flows and use them. However, the business will be limited to sending only 10 new Flow messages per hour." (Meta - Flow Health and Monitoring)

Blocked is the absolute version:

"Monitoring detected that the endpoint is unhealthy and set the status to Blocked. The Flow cannot be sent or opened in this state; you need to fix the endpoint to get it back to Published state." (Meta - Flows API)

The consequence of that asymmetry is a support conversation that goes nowhere. A campaign errors on 132069 while whoever is checking opens the Flow on their own phone, uses it end to end and reports that it works. Both are right. Sending is capped; opening is not. It is the same class of mismatch as a template that is approved and accepted but never arrives: the thing you can see is not the thing that is failing.

How do you read the alert that arrived first?

Through the flows webhook field, which is subscribed separately from messages on the WhatsApp Business Account. Meta is direct that this is the intended channel:

"Flow webhooks are the main way you can find out about production issues affecting your customers." (Meta - Flow Health and Monitoring)

and that the subscription is a thing you must confirm rather than assume: "You need to verify that your WhatsApp Business account is subscribed to Flows webhooks." (Meta - Flow Health and Monitoring)

That subscription is exactly what most integrations lack, because an inbox needs messages and nothing else. If the alerts have been landing in a handler that ignores unknown fields, the picture is the one the health guide describes:

"You will receive multiple alert webhooks before the Flow becomes Throttled or Blocked." (Meta - Flow Health and Monitoring)

The payload's Value object carries flow_id, event, message, threshold, alert_state, old_status, new_status, requests_count, error_rate, p50_latency, p90_latency and an errors array. event is documented as taking five values — FLOW_STATUS_CHANGE, CLIENT_ERROR_RATE, ENDPOINT_ERROR_RATE, ENDPOINT_LATENCY and ENDPOINT_AVAILABILITY — but the same page's version-expiry sample payload carries an event of FLOW_VERSION_EXPIRY_WARNING, a sixth value the table does not list. Do not throw on an unrecognised event; log it. alert_state is ACTIVATED or DEACTIVATED, so the recovery notice comes back down the same field.

If you never subscribed to flows, you are late rather than blind. The Flow node answers a health read on demand:

GET {BASE-URL}/{FLOW-ID}?fields=id,name,status,health_status

health_status returns a can_send_message value for each entity involved — the Flow, the WhatsApp Business Account, the business and the app each get their own row — and, where something is wrong, an errors array of error_code, error_description and possible_solution. It also takes an optional argument:

"To check that a flow can be used with a specific phone number, you can use the optional health_status.phone_number(PHONE_NUMBER_ID) parameter." (Meta - Flows API)

What the pull does not give you is the metric and the number. It tells you the Flow cannot send right now; the webhook is what tells you the p90 latency reached 8,000ms against a 7,000ms threshold half an hour ago. Use the read to confirm the current state, and the subscription so that next time you hear about it before the campaign does.

If the alerts are not arriving at all, the cause is usually the subscription rather than the code — the same set of checks as a verified webhook that receives nothing.

Why does a handler built from Meta's docs never match?

Because the two pages you need disagree with each other, and one of them disagrees with itself.

The Flows Webhooks page tells you to resolve an alert by looking its error_type up on the error codes page: "See Webhook Alerts and Endpoint Error Types section of Error Codes page for details and suggestions for resolutions." The sample payloads on that webhooks page spell those types in upper snake case. The error codes page it points at spells them in lower kebab and snake case. Two of the pairs are not even the same words.

A switch written from either page silently never matches what the other describes. No error, no warning — just an alert falling through to the default case and logged as unrecognised, which is the same as not receiving it.

There is a further trap in the same family. The error codes page lists an alert identifier spelled public-key-signiture-verification. The "Implement endpoints for Flows" guide spells the same alert correctly, referring to "client side errors public-key-missing or public-key-signature-verification" (Meta - Implement endpoints for Flows). What is established is that Meta's two pages disagree. Which spelling arrives on the wire is not something this page can confirm without a live payload, so match both and log which one you saw. The silence is the same one a mismatched X-Hub-Signature-256 produces: a comparison against the wrong bytes throws nothing.

Three more inconsistencies, all observed in the rendered Flows Webhooks page on 11 September 2026, and all worth coding defensively around rather than trusting:

• The Value object table defines new_status as "Previous status of the flow" — word for word the same definition it gives old_status. Evidently a copy-and-paste error, but it means the table cannot tell you which field holds which end of a transition.
• The CLIENT_ERROR_RATE sample payload's message says the rate "has reached the 5% threshold in the last 60 minutes" while the threshold field in the same payload reads 10. The prose and the number disagree inside one object.
• Two version-expiry samples carry a warning field and the availability sample carries an availability field, and neither appears in the Value object table at all. A parser modelled strictly on that table drops both.

And a unit trap that has nothing to do with documentation defects: thresholds are documented in seconds and delivered in milliseconds. The latency sample payload carries "threshold": 7000 and "p90_latency": 8000 for a ladder the prose describes as "1s, 5s, 7s". Compare against 7000, not 7.

What do 421, 432 and 427 mean coming back from your endpoint?

Most write-ups of Flow endpoint failures know only 421. Meta's Flows error codes reference documents three, and they mean different things.

The 421 retry is documented explicitly:

"The WhatsApp client will re-fetch a public key and re-send the request. If the request fails, a generic error will be shown on the client." (Meta - WhatsApp Flows error codes)

427 is the only one of the three that lets you put a user-visible string on the screen, by returning an error_msg in the response body. It is also the only one that changes what the customer can do next:

"A generic error will be shown on the client, and the CTA button will be disabled for the user. You can send a new message to the user generating a new Flow token." (Meta - WhatsApp Flows error codes)

That makes it the right code for an expired session, where "this order has already been confirmed" beats a generic failure — and where you do not want the customer tapping the same button into the same dead token.

One error type is commonly misread as a one-off: business-decryption-error is documented as the client having received the 421 error code from the business even after refreshing the public key. It does not mean one decryption failed. It means the retry loop above already ran and already failed, which is a worse state than a single bad request.

Is cannot_be_served a different problem?

For a blocked Flow, it is the same incident seen from the client end. Meta describes cannot_be_served as "The Flow message cannot be sent and opened by recipients", and the first cause it lists is the Flow not being in DRAFT or PUBLISHED state — which is exactly what BLOCKED is.

A throttled Flow is not the same thing. Meta says throttled Flows can still be opened, so a cannot_be_served report sitting beside a 132069 is pointing at some other cause, not restating the first one.

There are two others, and no amount of endpoint work clears either. Meta lists three in full:

"Flow is not in DRAFT or PUBLISHED state. Other common problems: WABA is blocked by Integrity. Check the Business account page for any quality issues. The version or data_api_version properties are missing in Flow JSON. Add these properties to the Flow JSON file" (Meta - WhatsApp Flows error codes)

The middle one is the single place where these two systems meet. Account-level enforcement is not a documented cause of 132068 or 132069 — those two definitions name endpoint health and nothing else — but Meta does name it as a cause of cannot_be_served. So check all three before assuming a cannot_be_served report is your endpoint incident wearing a different name. A restricted WhatsApp Business account is its own problem with its own remedy.

How does a Flow get back to Published?

By recovering, one rung at a time. The status machine never jumps in either direction:

"When a Flow's endpoint metrics begin deteriorating, the Flow status will first move to Throttled. Only if metrics deteriorate further is it moved to Blocked." (Meta - Flow Health and Monitoring)

and on the way back up, the same guide states that once the endpoint recovers the Flow moves first from Blocked to Throttled, and then from Throttled back to Published.

There is no publish button, no resubmission and no request-review step in that sequence. Republishing a Flow you have not changed does not address what monitoring measures, and Meta does not publish how long the observation takes. What you can watch is the flows webhook for a DEACTIVATED alert state on whichever event fired: that is the metric returning inside its threshold.

What should you check first when 132069 appears in a campaign?

In this order, because it goes from cheapest to most invasive:

1. Is the account subscribed to the flows webhook field? If not, subscribe first — most of what follows arrives in a payload you are not receiving. In the meantime, read health_status off the Flow node directly.
2. Search your logs for the last FLOW_STATUS_CHANGE, and for any latency, error-rate or availability alert in the preceding day. That names the metric and the threshold.
3. Measure your endpoint's p90, not its mean. A mean of 400ms hides a p90 of four seconds, and p90 is what the alert is computed on.
4. Check what your endpoint calls synchronously. A third-party API inside the request path is the commonest source of a p90 that clears every functional test.
5. Only then look at the Flow's own JSON. An INVALID_SCREEN_TRANSITION is a real cause, but a client-error-rate one, and the webhook will have said so.

A broadcast failing part-way through has several causes that look identical on a campaign report, and this is only one; a connection that reports itself healthy while nothing sends covers the others. What distinguishes this one is that the failure is measured on a server you own, in milliseconds, and Meta told you about it before it acted.

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.