I'm new in using WhatsApp cloud API, I've set up one webhook with my WhatsApp cloud API.but the problem is that after some time it sends an inbound notification of an old message again to my webhook.
-
what do you mean by an inbound notification? can you share some examples or more clarity about that notification, and what type of notification are you receiving `messages` or etc? and what type of notifications you have subscribed in webhook configuration? – turivishal Jul 09 '22 at 13:50
-
I have a similar problem. I am subscribed to messages only. I am using c#, so when I receive a message, I return an IActionResult of OK. What programming language are you using, because my assumption right now is that maybe the JavaScript example maybe returning more that just a status 200 response (although the response is response.sendStatus(200);) – kudzanayi Jul 17 '22 at 09:19
-
I'm using Python. @kudzanayi – parth panchal Jul 18 '22 at 07:47
-
1Have you managed to figure out a solution. A temporary un-scalable solution I am using is caching, this is just so I can finish the application. So its transforming the entire message to a json string and using that as the key. Are you using docker or some other platform? – kudzanayi Jul 20 '22 at 14:00
-
I haven't found any solution yet. I'm using the AWS ec2 instance. – parth panchal Jul 26 '22 at 06:37
-
Did you find a solution? Should I return 200, no matter what? Apparently if I not return 200 it will try to process the message later again – Eric Bellet Aug 08 '23 at 08:44
8 Answers
I will share my experience and maybe it can help some of you.
I was returning the status code 200 from my server. But Whatsapp Api Cloud still returned 15 notifications per message.
the problem was that in the past, maybe one month before. I had actived webhook messages notifications, but I didn't respond with the status 200. meanwhile I was building the sending messages backend logic. so , there were thousands of webhooks no responded with the Status code 200. So my facebook app went crazy, and when I decided to respond with the status code 200. it didn't work.
the solution was to create another facebook app. and the webhooks worked well.

- 412
- 3
- 6
-
Could that be the solution? Because the same thing happened to me, I don't know what else to try and my problem occurs when I send more than one message replying to the same message from the same user. I even tried to filter the time of the messages. I have posted a question regarding this topic, I would appreciate your help. I posted some of the code there. I swear I've tried everything, creating a new application would be the last option. – Izlia Aug 22 '23 at 23:27
-
By the way, one question, when creating the new application on Facebook, did you have to change the URL to which the webhook pointed? – Izlia Aug 22 '23 at 23:34
-
Thank you very much for answering me, I will be writing to you at night to send you more context of the problem. Thank you very much for your help – Izlia Aug 24 '23 at 01:40
If a notification isn't delivered for any reason or if the webhook request returns a HTTP status code other than 200, we retry delivery. We continue retrying delivery with increasing delays up to a certain timeout (typically 24 hours, though this may vary), or until the delivery succeeds.

- 21
- 1
You need to return HTTP 200
status to Meta to let the app know that message has been received successfully to the webhook
and served by your application so that meta will not retry to send the same message again.
Hope this helps.

- 812
- 1
- 10
- 23
Had the same problem, tried to delete the app but didn't work, I was still receiving old messages from the old app.
TLDR; don't use the same test number with more than one Facebook App.
Even creating a new app, Phone Number ID and Account ID were still the same, my speculation is that the webhooks payloads are tied more to the test phone number rather than the Facebook App. For this reason, if you have another application with the same test number and a not working webhook, it keeps sending the same messages to both webhooks.

- 11
- 1
-
Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Jan 09 '23 at 13:25
-
Thank you! It seems the case for me as well. I have "production" app and "dev" app. I have subscribed to the same url twice, then updated url in production to another one but messages were duplicating until I have completely removed production webhook. Then test number works as expected for dev. I we need to use always separate webhook urls (obviously) and separate test numbers, then it will not overlap for sure. – FelikZ Jan 30 '23 at 06:54
Within the POST defined in your Webhook, you should always return HTTP Status 200, check that this happens even within your Promises
-
1While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/late-answers/33691328) – ahuemmer Jan 27 '23 at 13:38
I experienced this issue as well. I did not go with the route of creating a new app because I a still developing and it is likely that one of the messages will fail during this period. I will try that route when I move to prod.
I however managed to find a workaround. The failed messages (the ones that didn't get a 200 ACk as per link https://developers.facebook.com/docs/whatsapp/on-premises/guides/webhooks) when they are re-sent, they still contain the timestamp of when they were initially sent. My work around was to filter old messages (> 12 mins) before I pass them further for processing. This works for my use case since it's a realtime chatbot. See a snippet of my javascript code below.
if (req.body.entry[0]?.changes[0]?.value?.messages ) {
req.body.entry[0].changes[0].value.messages = req.body.entry[0].changes[0].value.messages.filter((message) => message.timestamp > (Date.now() - 1000 * 60 * 60 * 0.2)/1000);
}
I hope this helps someone with a similar use case.

- 51
- 2
- 4
I know I'm super late but I think I've figured out the issue. Basically you have to send the status in the response text as well, not just set it. I was using NodeJS and ExpressJS and I had to change from response.status(200)
to response.sendStatus(200)
.

- 1
- 1
For me the problem was I was sending the 200 response to late. My solution was to push the webhook message to a queue and return the 200 response immediately. Then I could process the message asynchronously in the queue.

- 51
- 8