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.
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 created shopify app in which I have used webhooks for checkout/update. Webhook is working fine but I am getting this error message.
Your webhook for checkouts/update
at https://www.smsblitz.io/smsblitz/abondoned?shop=smsblitz.myshopify.com&user=iman%5Egemconsultinginc.org is
failing to return a successful response.This webhook has been
attempted 23 times. If your webhook continues to fail, it will be
removed and your application will not receive any more notifications.
Please help me to solve this issue.
Thanks
Initially I had the same problems. Following things could be taken care for getting out of the above issue.
Do not wait till you process the data in the notification. Soon after you get the webhook data, send back a 200 ok status code and then go further processing.
Make sure there is no white space before php tag or there is no echo statement available before you send the 200 status code to shopify because that will end up with error - header already sent.
Do not sleep with a timer as shopify wait for a 5 second time window and expect your 200 status code in between that time span.
You can save your processed data/id in a database. Shopify sends a webhook notification around 19(they say but sometimes more in real) times. So, you can try with first check with your database that the webhook notification is already processed by you or not. If processed send a 200 OK immediately.
Webhooks created through API are more reliable than the one created manually through the Shopify admin. (Though shopify claims they treat them same.)
Your webhook is not working fine. It is failing to respond to Shopify. So until you fix that, Shopify is counting the failures and letting you know, that soon, they will just stop that Webhook, and you'll have to recreate it.
To solve the issue, POST a webhook to your endpoint and verify it returns a 200 OK.
I have been reading Yodlee Docs at https://developer.yodlee.com/Yodlee_API/Webhooks for implementing webhooks
What i did is, first registered a webhook for one of my users using following end point
POST /{cobrandName}/v1/cobrand/config/notifications/events/{eventName}
Then i triggered a refresh for one of the account using following endpoint POST /{cobrandName}/v1/refresh
But seems that Yodlee doesnt hit my URL when refresh is completed or there is an error in refresh.
I also tried to add an account using FastLink to see if Yodlee hits my URL when an account is added. But it doesn't. I am not sure what exactly is the problem. Can you please help?
Although i have a dobt - Does the webhook hit only if add/edit/refresh account was done using the API and not FastLInk provided by yodlee?
I am using Account Agreegation API and Developer account for testing.
Webhook event notifications will work only when you try to add the account using YSL APIs (manually).It doesn't work with FastLink. I have been informed by Yodlee Support. They also informed me that till date they don't have any client using webhook service, which was bit scary to know.
Please find a simple example to use webhooks-
1)Subscribe event using this URL- http://webhook.info/post/FLQLMZMFJI
2)Initiate add account process
3)Open the following URL and find the refresh notifications -
http://webhook.info/#/watch/FLQLMZMFJI
Please note: As you have subscribed for webhook event now. Please unsubscribe first using
DELETE /{cobrandName}/v1/cobrand/config/notifications/events/{eventName}
Delete Subscription
Is it possible to get MailChimp or Mandrill to notify a webhook URL whenever a message is either created for a list, or scheduled to be sent, along with the list and message IDs?
I have a client that wants to intercept messages from his campaign, add special data from his server, then send the resulting template through his connected Mandrill account. I'm trying to figure out how to implement the first step in this process.
Although I know this is old someone may stumble into this thread, have you checked out the webhook information?
http://help.mandrill.com/entries/58303976-Message-Event-Webhook-format
It has an easy way to implement it inside the account. You just setup a URL to intercept and parse the incoming data. I recommend first saving the data then using a scheduled task to parse the job separately so you don't lose data (although mandrill will try 100x).
If the unique id is not enough for you with your events, and you are concerned about specific campaigns you can tag the emails upon send and they will have the tagged information with the incoming event.
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.