I post to some of my channels a standard suggested animation. Next, the bot presented in this channel can repost the animation over a file_id.
But later in a while, it starts to fail with the error 400: ad Request: wrong file identifier.
Once I post the same animation to the initial channel again it becomes available for bot again just with the same file_id
Who can I avoid the access lost?
Or is there a standard ttl for file_id to schedule an automotive refresh flow?
Related
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.
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.
Whatsapp webhooks documentation
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.
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.
Within the POST defined in your Webhook, you should always return HTTP Status 200, check that this happens even within your Promises
Webhooks for WhatsApp Business Accounts
I have successfully set up a DM bot with the Account Activity API. Everything works very well, except that sometimes the message sent to the bot (through the Twitter's web interface or mobile application) doesn’t fire a webhook to my server. The messages could be quick replies responses or plain text.
The reason is obviously not a downtime of my server since I tried to make a conversation between 2 webhook registered users (so my server receive the webhooks for both users) and for the same message sent, I have successfully received the webhook of the sender (the user) but not for the recipient (the bot).
As the bot isn’t in production yet, the reason is not an overload of messages. There is currently only 2 users that make conversations. From my experience, around 10% of messages are "lost".
I'm using the free (sandbox) Account Activity API tier, but as I understand the only differences between the free and paid versions are a higher number of subscriptions (I'm fine with 15) and the “Retries” feature. Regarding this feature, it is specified that “The Account Activity API provides a retry feature when the client’s web app does not return a ‘success’ 200 response for an account activity webhook event.”
It clearly states that the event failure concerns the client’s side, not the Twitter side. Considering this issue (my server doesn't receive the webhook at all), there is no guarantee that every event will be delivered even if in a paid plan.
This is a big inconvenience for bots since a button can only be clicked once, so the user must retry the conversation from the beginning (besides the fact that the bot "doesn't work"...)
So my questions are :
Is anyone here experience this issue ?
Is this a “bug or a feature” of the free Account Activity API ? I mean, at random the free tier doesn't fire the webhook on purpose (even if it's not specified in the docs) ?
Is there a way to see or measure the webhook failures Twitter side, via the dashboard for instance ?
A guess is that the events could be more accurate if the account is verified (with a blue badge) or hit a followers number threshold ? The treatment could be different due to the potential surge of events, so they are monitored with more ressources, thus more reliable ?
I already create a topic in the official Twitter forum and there is at least one other person in the same case, but no official answer from Twitter so far.
Thanks a lot !
BR,
Simon
I've got an official answer from Twitter :
Unfortunately it is not possible to achieve 100% delivery rate when there is only 1 delivery attempt for an event, which is why we have retries (and even then, retries are not a guarantee either). Things can go wrong; maybe internal issues in Twitter Data Centers, routing issues in the internet, hosting issues at your webhook, etc.
So from the time being, it seems that there's not way to have a 100% success delivery when you build a bot on Twitter.
Full answer can be read here.
I have been using the Stripe API and it's been calling my Webhook successfully for about a year.
But yesterday an issue occured for the first time. The webhook did not manage to succesfully complete its intended operation, but returned a 200 status code anyway, so Stripe didn't retry.
I have now fixed the error on the Webhook, but can't figure out how to make Stripe repeat the webhook call for this particular event. I can retrieve the event, but there's no button to resend. How to?
Stripe cli allows this stripe events resend IDOFTHEEVENT --live --webhook-endpoint=IDOFTHEWEBHOOK (replace IDOFTHEEVENT by the id of the event, and IDOFTHEWEBHOOK by the id of the webhook which you can find in the URL when you are on a webhook's page).
Otherwise you can copy/paste the event sent to the webhook and sent it to your endpoint with a tool such as postman.
It is possible to manually resend webhook events.
In the Stripe Dashboard, select Developers > Webhooks, then find the webhook your working with and press the little "resend" icon.
Note that for events which succeeded, you can still resend them by clicking the ellipsis and then "Resend" (this is a newer feature).
Since a 200 was returned, retrieving the event is going to be your best bet. Manual retries aren't currently possible (per https://stripe.com/docs/webhooks#responding-to-a-webhook):
In live mode, we will attempt to deliver your webhooks for up to three days with an exponential back off. In test mode, we retry three times over a few hours. Webhooks cannot be manually retried after this time, though you can query for the event to reconcile your data with any missed events.
When viewing information about a specific event through the Dashboard, you can check how many times we've attempted to send an event to an endpoint by clicking on that endpoint URL in the Webhook details section. This will show you the latest response we received from your endpoint, along with a list of all attempted webhooks and the respective HTTP status codes we received.
I am running an application using Instagram's RealTime API and when I subscribe to a tag initially all is working fine, I can see for sure my response times are all within 100ms back to instagram but after about an hour, hour and a half they randomly delete my tag subscription. I check and I am not rate limited so I setup something to check my subscriptions every 10 minutes and if the tag I was subscribed to isn't returned from instagram to re-subscribe it. When running that I get back a response that it is subscribed -
{ object: 'tag',
object_id: '...',
aspect: 'media',
callback_url: 'http://...',
type: 'subscription',
id: '4479168' }
but then when I check my subscriptions again using the API Console it shows there are no subscriptions.
Does anyone have any idea why Instagram is deleting my subscription automatically.
Did you validate/confirm the subscription? You didn't mention doing it in your question so that leads me to think that maybe it's timing out after not being confirmed?
According to the API docs a POST to make any subscription will trigger a GET to your callback_url that will include:
hub.mode - This will be set to "subscribe"
hub.challenge - This will be set to a random string that your callback URL will need to echo back in order to verify you'd like to subscribe.
hub.verify_token - This will be set to whatever verify_token passed in with the subscription request.
The example URL given is:
http://your-callback.com/url/?hub.mode=subscribe&hub.challenge=15f7d1a91c1f40f8a748fd134752feb3&hub.verify_token=myVerifyToken
After parsing that callback you have to send a response including the hub.challenge value and you should have a lasting subscription.
As far as I can tell, this happens when Instagram decides you are not responding fast enough. I noticed 8 separate IPs posting the exact same subscription info (identical HTTP requests) and my app apparently has some transient lag issues. It appears that if responses are not sent immediately (100s of ms) then Instagram silently deletes the subscription and there's no way to find out.
Solution was to dump the subscription model and just poll them instead.
Documentation on the Real-Time API is fairly sparse on the mechanisms behind the push notifications. Does the Foursquare API retry to POST a notification (checkin) if the receiving endpoint is unresponsive at the time? For example, here is Facebook's retry policy:
"If a change notification to your server fails, Facebook will retry again immediately, then a few times more, with decreasing frequency, over the next 24 hours."
Does foursquare have anything similar?
Foursquare does not retry push requests at this time. You can (albeit inefficiently) call /users/self/checkins?afterTimestamp=XXXX for each user with their access token to retrieve their recent check-ins in the event you believe you've missed check-ins.