WhatsApp error 132068 (Flow blocked): fix the endpoint and the Flow recovers on its own

WhatsApp error 132068 means the WhatsApp Flow you tried to send is blocked. Meta's error reference gives the description "Flow is in blocked state" and the solution "Correct the Flow", with HTTP 400. Behind that short text is Meta's Flow health monitoring: when the endpoint that feeds a Flow with data starts failing, Meta first throttles the Flow and then blocks it, and "sending and opening of the Flow is blocked". Nothing is wrong with the recipient or your number. The problem is the server your Flow talks to.

Throttled, then blocked

Meta's health monitoring page lists three states:

A Flow moves Published → Throttled → Blocked as its metrics get worse, and back the same way as they improve. If you saw 132069 earlier in the day and ignored it, 132068 is often the next step. Note that a block also stops customers who already have the Flow message from opening it.

What Meta measures

Health monitoring only applies to Flows that use data from your endpoint (the data_exchange actions that load the next screen, check a slot or validate a code). Meta watches three things:

• Endpoint or client error rate. Your endpoint returns errors, or responses the WhatsApp client cannot use: wrong encryption, a payload that does not match the screen, a missing field.
• Endpoint latency. Responses that take too long. Meta's advice is to "aim to return a response in less than 1 second".
• Endpoint availability. The endpoint is down, times out, or is not reachable from the internet, for example a server behind an office firewall or an expired TLS certificate.

What it looks like

Illustrative send response for an interactive Flow message while the Flow is blocked (wording varies):

{
  "error": {
    "message": "(#132068) Flow is in blocked state",
    "type": "OAuthException",
    "code": 132068,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "Flow with id 7712045893321456 is in blocked state."
    },
    "fbtrace_id": "Ab3QwP8nZr6LmK1tYcV0xHs"
  }
}

If you subscribe your app to the flows webhook field, Meta also sends status-change and endpoint alerts, so the move to Throttled reaches you before customers notice. Field names and thresholds are in Meta's Flows webhook reference; check them there rather than hard-coding values from an example.

Step-by-step fix

1. Stop sending the Flow in campaigns and bots. Every send fails, and a blocked Flow cannot be opened anyway.
2. Find the endpoint URL set on the Flow (in WhatsApp Manager under Flows, or GET /<FLOW_ID>?fields=name,status,endpoint_uri,health_status).
3. Check availability from outside your network: curl -s -o /dev/null -w "%{http_code} %{time_total}\n" -X POST https://flows.example.in/endpoint. A timeout, a TLS error or a 5xx is your answer.
4. Check your logs for errors on decrypting requests and on the ping health-check action, which the endpoint must answer. A rotated private key or a changed public key on the number breaks every request.
5. Check latency. Slow database lookups, a third-party API called on every screen or a server in another region add up. Cache what you can and return the next screen in under a second.
6. Fix the Flow JSON if the client errors come from it: a screen that expects a field your endpoint does not return produces client errors.
7. Wait for recovery. Meta says that once your endpoint improves, "WhatsApp monitoring automatically detects the changes and the Flow's state is updated." Watch the status move back to Published before resuming sends.

A worked example

Sunrise Clinic in Pune sends a booking Flow after patients tap "Book a visit". The second screen calls the clinic's endpoint for open slots with Dr Meera's calendar. On Monday the hosting provider renews the server's TLS certificate incorrectly. Requests from Meta fail the TLS handshake, availability drops, and by mid-morning the reception team sees 132069 after a handful of sends; by noon it is 132068 and patients who tap old Flow messages get nothing.

The developer reinstalls the certificate, confirms with curl from an outside machine that the endpoint returns in about 400 ms (illustrative), and checks that the ping action answers. The Flow returns to Published later that day without any action in WhatsApp Manager. Meanwhile the clinic replies to booking requests by plain chat, which works inside the 24-hour customer service window, so nobody is turned away.

Preventing 132068

• Monitor the endpoint like a payment page: uptime checks from outside your network, alerts on error rate and response time.
• Subscribe to Flow alerts and treat Throttled as an incident, not a warning.
• Keep responses fast: precompute slots, avoid chained API calls per screen.
• Rotate keys carefully: upload the new public key and deploy the matching private key together.
• Use static screens where data is not needed. A Flow that collects a name, city and preferred time does not need an endpoint at all, and a Flow with no endpoint has no endpoint health to lose.

WhatsApp Flows in Broadchat

In Broadchat, Flows are called Mini Apps and live under WhatsApp Mini-Apps → Mini Apps. Mini Apps built in Broadchat's editor are stored on Meta for your WhatsApp Business account and move through the statuses Draft, Published and Deprecated; they do not call a data endpoint of yours, so the endpoint health checks behind 132068 do not apply to them. Flows that your developers built elsewhere with an endpoint appear in the list after a refresh, which reads each Flow's status from Meta, and they are the ones to watch for this error. Submissions from any Flow can start a chatbot through the Mini-App Submission trigger.

Related reading: the WhatsApp API error codes cheat-sheet, WhatsApp interactive messages and what the WhatsApp Business API is.