- - Notice history

Customer Statement

Meta Incident 20th January 2026

Issue description and impact

Meta introduced breaking changes to the /media_id endpoint without backward compatibility. As a result, some valid requests were incorrectly classified as bad requests and triggered rate limiting logic on our internal service (which we call Unify) that is responsible for sending requests to Meta WhatsApp Business API. In parallel, unexpected response handling caused Unify service restarts. This led to temporary service instability and request blocking for affected clients using the /media_id endpoint.

Cause of the issue

Two independent changes on Meta’s side caused the incident.

First, Meta’s API started returning a Bad Request response when an optional phone number ID was included, even though the request was valid according to documentation. This behavior caused Unify’s rate limiter to block clients sending repeated requests.

Second, Meta changed the response delivery method for the /media_id endpoint from a fixed Content-Length payload to Transfer-Encoding: chunked. Unify’s handler did not anticipate this encoding, resulting in unhandled runtime errors and container restarts.

Mitigation steps

An initial hotfix was deployed to stabilize Unify by correctly handling chunked responses for the /media_id endpoint.

A subsequent release removed the phone number ID from proxied requests to Meta as a temporary workaround, preventing valid requests from being rejected and clients from being rate limited. Blocked clients were cleared once the mitigations were in place.

Additional monitoring was added to detect and alert on additional failures.

Prevention of recurrence & suggestions

Meta has acknowledged the issues on their side: 

Between 20 Jan 2026, 4:07 AM and 11:25 AM PST, some customers experienced errors when attempting to retrieve media using the WhatsApp Business API. The error message received was:

Invalid OAuth access token - Cannot parse access token."

This resulted in failed requests to the Get Media API endpoint, preventing customers from accessing media content as expected.

The impact was limited to the inability to retrieve media files, which may have disrupted business workflows relying on media retrieval.

The incident was triggered by a change in the media retrieval requests. This change inadvertently caused the Get Media API to reject valid OAuth access tokens, resulting in authentication errors for customers. The expected behavior was for the API to accept valid tokens and allow media retrieval.

The issue was not recurring and was directly linked to the recent change. Once the change was reverted, the errors ceased.

To prevent such issues from happening again, additional automated testing and safeguards will be implemented to ensure similar changes do not impact production traffic in the future. Besides that, enhanced monitoring and alerting for authentication errors on the Get Media API will be established to enable faster detection and mitigation.

—

Internally, we are reviewing Unify endpoints to ensure full HTTP RFC compliance.

Timeline

Incident timeline (UTC)

12:20 – First automatic alert triggered for elevated 5xx error rate
12:34 – 360D messaging engineering team began investigating
12:47 – Incident reported on our public status page
13:21 – Messaging engineering team applied a hotfix to prevent Unify service crashes, service stability restored but root cause still unknown
13:59 – Our L2 team indicates that clients are being blocked on the /media_id endpoint
14:00 – Messaging engineering team started investigating rate-limited clients
14:30 – Script prepared to clear clients blocked due to artificially induced rate limits on the /media_id endpoint
14:34 – Messaging engineering team identified unexpected behavior in Meta’s /media_id endpoint when the optional phone number ID was provided
14:58 – Previously blocked clients cleared again
15:03 – Case escalated to our Technical Account Manager (TAM) at Meta
15:28 – Messaging engineering team identified the full root cause
15:36 – Workaround deployed for the /media_id endpoint and blocked clients cleared again, preventing further impact
15:46 – Our TAM acknowledges the issue and indicates it is affecting multiple BSPs
16:21 – Incident marked as resolved on our public status page
19:25 – Meta applied fix and the situation stabalized allowing us to remove the workaround solution.

Meta has applied a fix. We'll monitor it closely.

A public RCA will be published on this status page as soon as all details are made available by Meta.

We have implemented a workaround to mitigate the issue.

Meta has acknowledged an issue on their side and confirmed it is impacting multiple WhatsApp BSPs. Meta’s engineering team is currently investigating the root cause.

We will mark this incident as resolved for the time being.
A public RCA will be published on this status page as soon as all details are made available by Meta.

Meta made a change to the /media_id endpoint by introducing a chunked Transfer-Encoding response. This caused temporary issues when fetching media content. We are releasing a workaround shortly to handle this change.

While a fix has been pushed, we are receiving some reports of errors when sending or retrieving media messages in certain cases. Our engineering team is actively investigating.

The issue appears to be resolved and all services are operating normally.
We will continue to monitor closely and provide another update shortly.

We implemented a fix and are seeing signs of recovery.
We are currently monitoring the situation and will update again shortly.

Our engineering team have identified the issue and is currently working on a fix. We will update again asap.

This incident has been resolved. The 360dialog Hub is fully operational.

The issue has been identified, and the service has been restored. We are currently monitoring the situation to ensure stability.

The issue is now resolved.

We have implemented a fix and are monitoring.