Intermittent WhatsApp media sending failure (Error 131053) while text messages work correctly

[ElPipe5897]

Hello team,

We are experiencing a recent issue when sending images through the WhatsApp Cloud API channel in Chatwoot.

Environment

Self-hosted installation on VPS (Docker)

Official WhatsApp Cloud API

Chatwoot running correctly for months

No recent infrastructure changes before the issue started

Problem

Over the last few days, image sending started failing intermittently.

Text messages are delivered correctly.

Some images are delivered successfully.

Other images fail with the following webhook error:

Error code: 131053
Media upload error
Downloading media from weblink failed with http code 429
Too Many Requests (ratelimit by fwdproxy)

The behavior is inconsistent: sometimes it works, sometimes it fails.

Observations

Server resources are stable (CPU and RAM normal).

No configuration changes were made before the issue started.

The failure seems to occur when WhatsApp attempts to download the media file.

The issue started recently without apparent modifications on our side.

Questions

1. Have there been any recent changes in how Chatwoot handles media delivery to WhatsApp?

2. Is there any recommended configuration adjustment to prevent this intermittent behavior?

3. Is this a known behavior related to download limits or retry logic from WhatsApp?

Any guidance would be appreciated.

[joseinaciotoro]

I'm experiencing the same issue. Since I have control over the development process, I've tried using the media ID to send the file, but it's intermittent. It seems the problem is with the Hostinger "org": "AS47583 Hostinger International Limited" KVM 8 VPS server. My error: Downloading media from weblink failed with http code 429, status message Too Many Requests, ratelimit reason: Request ratelimit by fwdproxy. Details: [GlobalCountingRatelimiter] Request hit ratelimit policy 20----- client identity matcher .*, destination matcher asn_list: 47583

[Daypher]

same here while sending an audio in the web site it said 131053: Media upload error, it seems that the problem it's only in the web site since I was able to send them through the mobile app.

[jksadmgi]

Same problem here, can't sent audio, imagem, files, sometimes work and others not... text is working fine.

[allan10k]

I’m running into the exact same issue! I tested this on two Hostinger VPS plans (KVM1 and KVM4), and both triggered the same error. I was forced to migrate my media storage to a Cloudflare free solution; while that reduced the frequency, the error persists. To make matters worse, it’s no longer generating error logs, and I’m experiencing intermittent failures where media messages from certain contacts aren’t being received at all

[joseinaciotoro]

My conspiracy theory is that by closing the self-managed servers with N8n, Flowise and other things in Docker, having thousands of users, META put limits on them. This is what I'm migrating to AWS. I also contacted Meta's direct support as a developer... What's really happening?

When your bot does this:

Sends an image with an external URL

Meta tries to download it from your server

Many downloads from ASN 47583

Meta activates the GlobalCountingRatelimiter

Result: HTTP 429

Meta is limiting traffic from that provider, not your application individually.

🎯 So…
❌ Changing code → DOESN'T fix it
❌ Changing Cloudflare → DOESN'T fix it
❌ Changing proxy → DOESN'T fix it
❌ Changing WABA → DOESN'T fix it

Because the blocking is by ASN.

🚀 Real Solutions
🥇 Best (Professional) Solution

Move the service to:

AWS

DigitalOcean

Google Cloud

Vultr

Any provider that is NOT ASN 47583.

What is "AS47583"?

AS = Autonomous System

It's an identifier that groups IP ranges under the same provider.

In your case:

AS47583 = Hostinger International Limited

That is:

👉 Your VPS is within Hostinger's global network
👉 Your IP address is part of Hostinger's IP address block
👉 Meta identifies your server as traffic originating from Hostinger

In simple terms:

It's as if Meta were saying:

"I'm receiving too much traffic from Hostinger (ASN 47583). I'm going to limit that provider."

And since you're within that provider, it affects you.

📌 So this DOES NOT mean:

❌ That your account is blocked
❌ That your WABA is suspended
❌ That your app is misconfigured

It means that your server is on a network that Meta is rate-limiting.

[brazilmarcelo]

I'm facing the same issue, I participate in a community where many other people are also experiencing the same problem. I've been using version 4.10.1 for a while and it was working without any issues. It started failing from Friday 2026-02-06. Yesterday, on 2026-02-11, it got worse.

[allan10k]

Which VPS are you using? Is it Hostinger too? And is the rest of your community on Hostinger as well?

[brazilmarcelo]

I'm also using Hostinger for this.

[joseinaciotoro]

Hostinger's response... apparently, I wasn't so crazy after all... Upon further investigation, it seems the main issue is that Meta/WhatsApp applies rate limits based on Hostinger's ASN (AS47583), so even new VPS deployments within the same ASN remain blocked. The solution is to deploy your VPS in a data center with a different ASN, which can bypass these restrictions.

Important: Reinstalling your VPS in a new location will permanently delete all existing data, including backups and snapshots. To avoid losing important information, be sure to create and download a full backup via SFTP before proceeding.

To reinstall your VPS in a new location...

[brazilmarcelo]

Looks like I'll have to switch to Hetzner then.

[allan10k]

I became wary of Hetzner and Contabo because a brief search informed me that their IPs are "dirty." The low price is tempting for malicious individuals. If the problem with Hostinger was the "n8ner" craze, I'll avoid it.

[brazilmarcelo]

I understand, but the people in the group want to participate; they're all at Hetzner. Those who are there aren't having any problems.

[joseinaciotoro]

META responded to me and asked for information that I already sent, I await a response, I will be updating.

After reviewing the information available, the HTTP status code 429 (Too Many Requests) typically means the media URL host/server is receiving a high volume of requests within a short period of time. As a result, the server temporarily throttles or blocks additional requests, and the media download attempt may fail at that moment.

To help us investigate further and could you please share the following details:

1. Message ID (starting with wamid)
2. WABA ID
3. Media ID or Media URL
4. Phone number

If possible, please also include:

• The approximate date/time when the error occurred (with timezone)
• Whether the issue happens consistently or only at specific times

[brazilmarcelo]

Where did you get this information from META? I also need to send this to the META team.

[ElPipe5897]

Hello everyone,

Thank you all for your comments and for confirming that I’m not the only one experiencing this issue.

Based on the responses, it seems several of us are currently facing the same error, especially those hosted under Hostinger ASN (AS47583), with the ratelimit by fwdproxy message.

I am currently in contact with Hostinger to see if they can provide any additional insight or support from the network side, as this appears to be related to how WhatsApp attempts to download media files.

Migrating the entire infrastructure to another provider would be a major and complex decision, so before taking that step I want to validate whether this is specifically an ASN/network-level rate limiting issue.

I will keep this thread updated with any relevant information I receive.

Thanks again for sharing your findings.

[cayquecastellucci]

Perfeito, estamos ansiosos no aguardo!

Perfect, we're eagerly awaiting it!

[brazilmarcelo]

After receiving the information about the ASN, I spoke with the group members and they suggested adding this to the Chatwoot

stack: extra_hosts: mmg.whatsapp.net: 31.13.85.51 environment:

This way, I can restrict META traffic to only that IP address.

[ElPipe5897]

Thanks for sharing that solution.

Did you test it in your environment?
Did it work consistently for you?

I’d really like to know whether it actually eliminated the 131053 / 429 errors and remained stable over time, or if it was only a temporary improvement.

[brazilmarcelo]

I haven't tested it; people said that out of the various IPs that META uses to send messages, I'm going to have my server receive messages from only one IP, the one that's configured there. That might solve the problem, but if META stops using that IP, it could cause more problems. I'm going to switch this server to Hetzner.

[Ranyelton]

Consegui uma alternativa gambiarra pra essa situação até termos uma solução oficial ou antes de fazer uma migração completa e complexa.

A ideia é: quando o Chatwoot falhar no envio de mídia pro WhatsApp com “131053: Media upload error”, a gente intercepta o erro via webhook, faz o upload da mídia direto pela WhatsApp Cloud API e envia a mensagem “por fora”. No Chatwoot, fica só um registro interno avisando que foi reenviado.

Como eu fiz (passo a passo)

1. Criar um Webhook no Chatwoot

• Vá em Settings → Integrations → Webhooks
• Crie um webhook apontando pro seu endpoint (usei n8n, mas pode ser qualquer ferramenta)
• Marque o evento Message Updated (message.updated)

2. Receber o evento no n8n (ou equivalente)

• Crie um Webhook (POST) pra receber o payload do Chatwoot.

3. Filtrar apenas quando for o erro de mídia

• Adicione um IF/condição checando o campo:

  • body.content_attributes.external_error == "131053: Media upload error"

• (Recomendado) também filtrar pra evitar ruído/loop:

  • mensagem status == failed
  • message_type == outgoing
  • attachments.length > 0
  • ignorar mensagem private == true

4. Baixar a mídia que falhou

• Faça um HTTP GET no attachments[0].data_url (ActiveStorage do Chatwoot)
• Configure pra baixar como arquivo/binário (pra usar no upload em seguida)

5. Fazer upload dessa mídia direto no WhatsApp

• Chame o endpoint/ação de upload de mídia da WhatsApp Cloud API
• Guarde o media_id retornado

6. Enviar a mensagem diretamente pelo WhatsApp (fora do Chatwoot)

• Chame o endpoint/ação de send message da WhatsApp Cloud API
• Tipo: image (ou o tipo correspondente)
• media_id = o id retornado no passo anterior
• to = número do contato (eu puxo do payload do Chatwoot e removo o +)
• caption (se existir) = o body.content da mensagem original

NÃO TENTE USAR O ENDPOINT DE SEND MESSAGE COM LINK DIRETO, FAÇA O UPLOAD PRIMEIRO E SÓ DEPOIS ENVIE A MENSAGEM COM O ID DA MÍDIA

7. Registrar no Chatwoot (pra equipe entender o que aconteceu)

• Por fim, eu chamo a API do Chatwoot pra criar uma mensagem privada na mesma conversa, tipo:

  • “✅ Imagem Reenviada pelo Servidor”

• Eu uso in_reply_to apontando pro ID da mensagem que falhou, pra ficar amarrado no histórico.

Observações importantes (pra não dar dor de cabeça)

• Isso é workaround temporário: a mensagem é enviada pelo WhatsApp “por fora”, então o Chatwoot não vai ter o envio oficial como se tivesse sido ele.
• Evite reenviar em loop (por isso o filtro de failed/outgoing/not private ajuda muito).
• Hoje eu tratei o primeiro anexo (attachments[0]). Se quiser cobrir mais de um arquivo, dá pra colocar loop nos attachments.

Se alguém quiser replicar, o básico é: Chatwoot Webhook (message.updated) → checa external_error 131053 → baixa data_url → upload mídia no WhatsApp → send message no WhatsApp → nota privada no Chatwoot.

Espero que isso ajude alguns de vocês temporariamente.

[allan10k]

Marcelo, "migrar" foi uma palavra forte, perdão kk. Recriei do zero, conectei o WhatsApp Cloud API e está rodando.
Quanto aos 100$, ele dá no primeiro ano e tem umas missões que pode chegar a 200$, não tive tempo de olhar ainda como funciona. A validade desses créditos é de 1 ano. Tive um problema quanto a compra da VPS de 2gb de RAM, mas consegui uma adaptação técnica (aumentar swap para 4gb) com a de 1Gb e está funcionando "ok". Notei uma pequena lentidão só na pagina de Login inicial mas funcionamento está ok. Se tudo estiver ok e continuar funcionando, não pagarei VPS por 1 ano.

[brazilmarcelo]

Vou ver os preços deles, preciso de uma VPS mais parruda, pelo menos 16gb de Ram e 8 cpu's.
Vou cotar os valores deles, se conseguir esses 100 doletas pra iniciar e o preço for compatível, levo tudo pra lá.

[ElPipe5897]

Hi Ranyelton, thank you very much for sharing this solution.
I think it’s a very good alternative to solve the issue without having to migrate the VPS.

I’m going to implement it and hope everything works smoothly.
I really appreciate your help and the time you took to explain it.

I’ll keep you posted if anything comes up.

[ElPipe5897]

The solution was good, stable, and clear. It essentially automates what used to be a manual process, allowing us to keep operating without having to fully migrate the server.

Yes, it’s a workaround, but it’s a well-built patch that keeps the automation running and allows us to continue working while we wait for Hostinger, Meta, and Chatwoot to resolve the root issue.

Thanks to everyone who participated and contributed ideas until we reached a stable solution.

At this moment, there are two possible paths:

Implement Ranyelton’s patch.

Migrate the server to a different infrastructure.

Thank you all.

[velascodavid]

Estou com um problema na condição do fluxo.

Quando avalio:
{{ $json.body.content_attributes?.external_error }} → retorna undefined
{{ $json.body.conversation.messages[0].status }} → retorna "sent"

Porém, na prática, o envio de mídia falha no WhatsApp com o erro:
131053: Media upload error

O Chatwoot marca a mensagem como "sent", mas o erro só aparece depois no webhook de status do WhatsApp.

Existe alguma forma de o Chatwoot propagar esse erro (131053) para a mensagem ou para o payload do webhook, ou a única maneira correta é tratar isso exclusivamente pelo webhook do WhatsApp?

n8n:

chatwoot:

Muito obrigado pela sua ajuda.

[PedroHenriquePdR]

What has been solved for me:
I moved my Chatwoot from Hostinger to another server (different ASN ID).
It works fine until the moment.

I don't know if Hostinger could solve this problem itself; I've decided not to wait for that.
To resolve it definitively, I think that Chatwoot should send the media directly via the WhatsApp official API.

Thanks for all!

[brazilmarcelo]

I'm doing the same, moving all my servers away from Hostinger.

[Ranyelton]

Conseguiu manter o histórico de conversas com clientes após a migração?

[Ranyelton]

Estou com a teoria de que o problema pode estar relacionado ao espaço de armazenamento disponível na VPS, o que teria causado lentidão e aumento da latência. Você poderia informar quanto de espaço estava ocupado na VPS da Hostinger antes da transição, enquanto o problema ainda ocorria?

[PedroHenriquePdR]

@Ranyelton I migrated all Docker containers to a new server on a different hosting provider (from Hostinger to DigitalOcean). To preserve the full message history, I did a PostgreSQL dump/restore of the database. I also transferred all files from the original MinIO bucket to DigitalOcean Spaces (S3-compatible storage).

I don't think this issue is related to storage size — it seems to be an API architecture problem. Chatwoot sends media via URL ({"document": {"link": "https://..."}}) and Meta's fwdproxy downloads the file from the server. When too many Chatwoot instances share the same hosting provider (same ASN), Meta rate-limits the entire ASN, causing error 131053 for all users on that provider.

A more robust approach would be for Chatwoot to upload media directly to WhatsApp using POST /{phone_number_id}/media and then send the message with the returned media_id, which is how n8n handles it and avoids this issue entirely.

[allan10k]

Taking advantage of the comment above, I moved from Hostinger to a 1GB AWS server and yesterday there were almost 750 support requests without any reported problems.

[Ranyelton]

Conseguiu manter o histórico de conversas com clientes após a migração?

[allan10k]

Nem tentei. E assim, na API oficial por causa da janela de 24h eu só recomendo para clientes que sejam de atendimentos rápidos, que não necessitem de histórico. Pessoal entendeu e ficou feliz que voltou a ter a confiabilidade. Mas o que eu fiz como "backup": Deixei ativo para acesso na hostinger o Chatwoot antigo e vou deixar até o vencimento, eles nem logaram mais.

[Ranyelton]

Estou com a teoria de que o problema pode estar relacionado ao espaço de armazenamento disponível na VPS, o que teria causado lentidão e aumento da latência. Você poderia informar quanto de espaço estava ocupado na VPS da Hostinger antes da transição, enquanto o problema ainda ocorria?

[jksadmgi]

✅ Como eu resolvi (sem migrar nada)

Consegui resolver o problema aqui e vim compartilhar porque pode salvar alguém de migrar tudo à toa.
Pelo menos pra mim funcionou.

Eu estava com o seguinte cenário:

• Texto no WhatsApp enviava normal.
• Mas quando enviava imagem/anexo pelo Chatwoot, simplesmente não chegava.
• Não aparecia erro claro no console.

Eu já estava quase pensando em migrar de VPS…
Mas o problema não era o servidor.

O que realmente estava acontecendo:

No WhatsApp Cloud, quando você manda um anexo, a Meta precisa baixar o arquivo a partir de uma URL gerada pelo Chatwoot.
E aí vem o pulo do gato:

Se o Chatwoot está usando storage local (disco), ele gera URLs de download/redirect do próprio servidor.

Dependendo do ambiente/rede/proxy/CDN/host (ex.: rate limiting, firewall/WAF, proxy/reverse proxy, etc.), essa URL pode ficar instável, demorar, falhar, ou não ser acessível “de fora” exatamente no momento em que a Meta tenta baixar.

Resultado: texto vai, mas anexo falha/intermitente (parece bug aleatório).

✅ Como resolvi sem migrar nada

Eu resolvi colocando o ActiveStorage do Chatwoot pra usar S3 (bucket).
A partir daí, os anexos passaram a ter uma URL mais estável e acessível pro WhatsApp Cloud baixar, sem depender do “disco/local” do container.

Basicamente, o objetivo é:

Meta precisa baixar rápido → então o arquivo tem que estar num lugar que entregue rápido e de forma confiável → S3.

Passo a passo (o que eu fiz)

Criei/usei um bucket S3 e peguei:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION
S3_BUCKET_NAME

Configurei no Chatwoot e no chatwoot-sidekiq (env vars):

ACTIVE_STORAGE_SERVICE=amazon
AWS_ACCESS_KEY_ID=xxxx
AWS_SECRET_ACCESS_KEY=xxxx
AWS_REGION=us-east-1
S3_BUCKET_NAME=seu-bucket
S3_ENDPOINT=https://s3.us-east-1.amazonaws.com

Fazendo isso, o Chatwoot passa a servir os anexos via S3, e o WhatsApp Cloud consegue baixar o arquivo sem depender do ActiveStorage local da VPS.

[allan10k]

Comentei isso acima. Fizemos o mesmo logo no inicio e os clientes perceberam que algumas imagens ficavam com 1 tick e não enviava. Parava de acontecer o error 131053 e não gerava log, mas continuava de forma intermitente sem enviar alguns conteudos. Para piorar ainda acontecia o mesmo erro no recebimento.

[jksadmgi]

Eu vi que você comentou sobre migrar a VPS para 1GB AWS server e não manter tudo na hostinger e só trocar o Bucket s3 no chatwoot. Quanto ao erro 1 check, ele quer dizer que foi enviado, mas não entregue, não significa que o cliente não vai receber. Pode ser que o usuário ficou sem internet. Quando aparece as duas (2 checks) delivered. Já em relação ao erro do (continuava de forma intermitente) Load Sending, esse erro está relacionado ao sidekiq, que muito provavel, foi implementado, mas não "restarted" aí ele lia a URL da mídia, mas não conseguia baixar e enviar devido ao erro .env.

Aqui por enquanto segue normal.

[jksadmgi]

Quando você manda uma mensagem de mídia, como não está mais no storage local, cada status precisa ser atualizado meio que manualmente... Mas tudo entrega....

Quando você manda, ela fica carregando...
mas se sair da conversa e abrir novamente, a imagem vai aparecer com um 1 Checked..

Se o usuário abrir ou receber, se sair de abrir novamente, no front do chatwoot, vai aparecer delivered, 2 checked.

Só websockt local que normalmente contece via client-side que não atualiza. Porque os dados não estão mais no local. Mas tudo está lá e enviando.. Aí pra ter uma visualização no front, só abrir ou sair da conversa, que o sistema já puxa os dados atualizados.

[bocmx]

Facing a similar problem here.
I'm receiving this error code when received a message from a person, and reply it (service window):

'131047: Re-engagement message'

But as I said the persons are starting the conversation with us (business), and we did't sent any previous template to them, and we get the error when we answer the message with a free form message.

[Ranyelton]

Isso acontece por causa do delay no recebimento/sincronização da mensagem.

Provavelmente o cliente enviou essa mensagem há mais de 24 horas, mas o Chatwoot só reconheceu e registrou ela agora, como se tivesse acabado de chegar. Como a janela de 24h já passou, ao tentar responder aparece o erro 131047 (Re-engagement message)...

[ElPipe5897]

I’m currently facing both issues:

Error code: 131053 – Media upload error
131047 – Re-engagement message

I managed to mitigate them using Ranyelton’s patch. I understand this is not a definitive fix, but it allows me to keep operations running while I continue investigating whether the root cause is related to Chatwoot itself or if migrating the server would be the proper long-term solution.

What I did was implement a small automation to handle message re-delivery when the error occurs. It’s essentially a controlled resend flow that prevents the process from breaking.

For now, it’s working and stable enough to continue production usage.

[ElPipe5897]

https://github.com/orgs/chatwoot/discussions/13565

[pabloDevCL]

Facing a similar problem here. I'm receiving this error code when received a message from a person, and reply it (service window):

'131047: Re-engagement message'

But as I said the persons are starting the conversation with us (business), and we did't sent any previous template to them, and we get the error when we answer the message with a free form message.

this is an error from saturday in my chatwoot, a thread was created with this bug... you could help us and create a new thread with this because smell like a chatwoot problem

[jonataslessaduarte]

+1

[luanstartflow]

I was experiencing this issue with a Hostinger VPS. I only changed the MinIO endpoint in the Chatwoot stack to one hosted on Contabo, and that resolved the problem.

[joseinaciotoro]

SOLVED: I'm sharing my experience. I work with a Laravel SAS application for sending mass messages, using a bot and AI through the official WhatsApp API connection. As I mentioned before, the dreaded code 429 appeared. After trying to capture the MEDIA_ID and using the Facebook URL, the error continued intermittently. After reviewing the issue and consulting with META support, it was determined that META was limiting ASN 47583 (Hostinger). When I spoke with Hostinger, their response was to buy another VPS. I had a KVM 8 with them, and migrating it only to have it fail again wasn't an option, given that META is applying control to the entire provider. So I decided to start the migration to an EC2 server, which was completed successfully. Upon starting testing, everything is working normally; there are no errors, and images are being sent as before without any backend adjustments.

I'm sharing the responses:

HOSTINGER - Upon review, it appears the main problem is that Meta/WhatsApp applies rate limits based on Hostinger's ASN (AS47583), so even new VPS deployments within the same ASN are still blocked. The solution is to deploy your VPS in a data center with a different ASN, which can bypass these restrictions.

Important: Reinstalling your VPS in a new location will permanently delete all existing data, including backups and snapshots. To avoid losing important information, be sure to create and download a full backup via SFTP before proceeding.

META: Thank you for reaching out and sharing the details of your issue.

I have thoroughly investigated the error related and reviewed the logs. It appears that Error Code 429 has occurred multiple times recently. Upon further examination, I found that this error is due to a failure in downloading media from the provided URL, which is returning an HTTP code 418.

To resolve this issue, please consider the following steps:

Check Server Configuration: Ensure that the server hosting the media file is properly configured to handle requests. This includes verifying that the server is not experiencing any downtime or overload.
Review Server Logs: Examine the server logs for any specific errors or exceptions that might be causing the 418 error. This can provide more insight into the underlying issue.
Check for Temporary Issues: Sometimes, server errors can be temporary. If possible, try re-uploading the media file or using a different hosting service to see if the issue persists.

Alternatively, you can upload the media directly to Meta's server and obtain a media ID. Using the media ID instead of the media URL might resolve the issue. Here is a detailed guideline on how to upload media: https://developers.facebook.com/docs/whatsapp/cloud-api/reference/media/#upload-media.

[leofhurtado-png]

Hola,
Tuve ese problema, enviando imágenes y audios, lo solucione con Amazon S3.

[mariofox]

I can confirm: I was having the same issues with media and severe delays on messaging delivery for the past few days. I had Chatwoot hosted in Hostinger VPS.
I followed the advice and migrated to a new VPS provider (Hetzner in my case) and now it is working perfect.

[Ranyelton]

O resultado foi instantâneo ou demorou algum tempo até resolver desde a migração? Fiz a migração recentemente e o delay no recebimento das mensagens permanece, apesar de a solução para o envio parecer estar ok (desde que mudei o STORAGE).

[mariofox]

To clarify: I migrated the entire Charwoot stack from Server. I was on Hostinger VPS, and I migrated my Chatwoot app and PostgreSQL db to Hetzner, and the issues were immediately solved. No more delays in messaging delivery, no more delays in messages received and no more media issues.

For me it was not enough to configure the attachment storage to S3 (I already had the attachments configured to be uploaded to Cloudlare R2), but the issue was specifically with Hostinger. After migrating to Hetzner, everything is working perfect