Twilio has provision for configuring callback URL while sending SMS, which is notified of events relating to changes in the delivery state of SMS.
What happens if my application misses one of these callback events? Say for example when my server is down and the callback request encounters a 502 or 500 response.
Does Twilio retry the callback?
If yes, how many attempts are made before abandoning the event notification?
Hope this thread isn't SUPER dead...
I set out to solve this problem myself by making twiliq.com. Disclosure: I'm the dude that made this thing.
You set it as your backup URL endpoint and it'll replay the message as often as you configure until your server recovers.
Twilio developer evangelist here.
Twilio webhooks (for SMS or phone calls) do not make retry attempts to the same URL if your application fails to respond with a 200 response.
However, you can supply a fallback URL that Twilio will request with the same parameters if your primary URL fails. We recommend that this fallback URL is not part of the same application so that if your main application is down, you can recover and continue the conversation, save the errors for later or return an error message to your user.
There is more detail on how best to use fallback URLs on the Twilio site.
Since an answer was posted for this Twilio has added support for retry attempts on webhooks. By default it will retry once on TCP connect or TLS handshake failures, but the type of failures it retries for can be adjusted and the number of retries can be set anywhere between and including 0 and 5.
Documentation can be found here:
https://www.twilio.com/docs/usage/webhooks/webhooks-connection-overrides
Related
I'm implementing a Handler for the DISCONNECT Intent, and by reading the online documentation https://developers.google.com/assistant/smarthome/reference/intent/disconnect, I see that it is no such response format and it is not a reference in case of fail event, when for example we return an error in event that we didn't properly handle the disconnect or Google API did not reach our server. Does Google Assistant implement some sort of automatic retry logic so that in event of error it automatically resends the requests for a certain amount time. In other words is it a way to tell to the google assistant to retry or return some error to the user that made the DISCONNECT request?
There is no response format for the DISCONNECT intent in the https://developers.google.com/assistant/smarthome/reference/intent/disconnect documentation because nothing is returned when the action.devices.DISCONNECT intent is executed (eg. Google does not retry based on your response status code). You can find more information on this at https://developers.google.com/assistant/smarthome/develop/process-intents#unlink
After an action.devices.DISCONNECT intent is sent, the Assistant stops sending any more intents for the user who has just been disconnected, and the associated cloud service also stops calling Home Graph APIs (Request Sync and Report State) for their devices and a SYNC request is triggered.
I'm implementing server-side application that manages subscriptions for IOS application.
To control account state(subscription is active or not) on the backend I'm using Apple Server-to-Server Notifications
Documentation saying:
Respond to Server-to-Server Notifications Your server should send an
HTTP status code to indicate whether the server-to-server notification
post succeeded:
Send HTTP 200 if the post was successful. Your server is not required
to return a data value.
Send HTTP 50x or 40x to have the App Store retry the notification if
the post was not successful. The App Store makes several attempts to
retry the notification over a period of time but eventually stops
after continued failed attempts.
But it is not clear which exactly retry policy apple following in case of server error on my side.
I'm looking for the answer to the following questions
How many retries apple will do?
With which interval between retries?
The retry policy for App Store server notifications depends on the version of the server notification. It retries as follows:
For version 1 notifications, it retries three times; at 6, 24, and 48 hours after the previous attempt.
For version 2 notifications, it retries five times; at 1, 12, 24, 48, and 72 hours after the previous attempt.
See here for details.
Refer: https://developer.apple.com/documentation/appstoreservernotifications/your_server
Upon receiving a server notification, respond to the App Store with an HTTP status code of 200 if the post was successful. If the post was unsuccessful, send HTTP 50x or 40x to have the App Store retry the notification.
If the App Store server doesn’t receive a 200 response from your server after the initial notification attempt, it retries three times. App Store retries at 6, 24, and 48 hours after its initial attempt. While App Store server notifications report state changes in real-time, you can always initiate receipt validation to get an up-to-date receipt. For more information
As you said Apple does not provide a clear answer in the documentation. But, from the Apple WWDC 2019 conference video: https://developer.apple.com/videos/play/wwdc2019/302/?time=637
"However, should you not return a 200 response, we will retry up to
three times to resend the notification to you"
Some manual testing suggests that they retry message for one hour.
Apple will attempt to retry 3 times over 3 days.
I have followed the steps to setup the Facebook Messenger platform. The verification GET web hook request work perfectly, as does the subscribe but when I submit the chat I keep getting the follow Developer Alert:
Hi Norah,
We've noticed that your Webhooks subscription for callback URL https://{domain}/v1/webhook has not been accepting updates for at least 16 minutes. Please verify that your callback server is functioning so you may continue to receive updates. If you need to update your callback URL, see https://developers.facebook.com/docs/messenger-platform/webhook-reference#webhook_setup
If your callback URL continues to fail to accept updates for 8 hours straight, we will disable your subscription. To reactivate the subscription, make a POST request with the same parameters, and it will be reactivated.
My post request works through POSTMAN.
Please can someone help me! This is driving me nuts!
Do you have logs on your server for that post requests?
Facebook requires you to return status code 200 for the post request, so they know that you successfully received it. When they havent, they try it again and if that still fails after several times, they will give you this alert.
Maybe facebook uses another content-type or message content than you used with postman.
Your server logs should give you more insights about that.
Depending on what Webhook events that you have subscribed for a page, there will be callbacks for those events, and more, on the url you have specified in the Web Hook set up.
If you had subscribed to the message_deliveries event, every time a message is sent, whether from a user to your page or from your page to a user, there is a, maybe more, calllback with a Message Delivered json object. The Webhook Reference has an example of the Message Delivered json object, but no specification or explanation on what the fields mean.
Occasionally I find that an undocumented Read callback is received, sometimes. The undocumented json data for this is like:
{"object":"page",
"entry":[
{
"id":"1722858134648129",
"time":1465407550812,
"messaging":[
{
"sender":{"id":"1131485883560113"},
"recipient":{"id":"1722858134642218"},
"timestamp":1465407550868,
"read":
{
"watermark":1465407548057,
"seq":428
}}]}]}
Essentially, you must code your callback to handle ALL types of json data gracefully, including unknowns, even though you may not be ready to process them further. For those that you are not ready to handle or uninterested in, return nothing with Http status code 204 (in fact every callback should return 204 as the type is void).
If you handle only those types of json data you are interested in, any unexpected json data will most likely raise an exception in whatever language your web callback code is written in and result in a 500 server error returned to Facebook. It is this 500 error that is causing Facebook to make that complaint in your question.
I am able to post trip requests, get estimates and ask for trip statuses, both in sandbox and live.
However, I am starting implementing status push notifications via webhooks and have hit a problem: I don't receive the notification (on sandbox). I have tried a couple of different URLs and servers to no avail. When pushing the notification ourselves from postman it works.
Do status push notifications via webhooks work on sandbox? If not, is there a way to test them?
According to the Webhooks documentation you should receive notifications every time you update the status of a ride request in sandbox mode.
Sandbox
When making Requests in the sandbox environment, we will also emit
webhook events for simulated trips. The requests.status_changed event
will be emitted every time the status of a simulated Request changes.
The requests.receipt_ready event will be emitted once a Request’s
status changes to completed.
Is you Webhook URL HTTPS enabled?
If this doesn't work you should consult the support team by visiting https://help.uber.com or by emailing support#uber.com.
If you want an easier way to debug, try setting up Ngrok
and then change the webhook URL in your developer dashboard to the link you get from Ngrok. That should allow you to debug the Webhooks issue on your local machine and verify that there is nothing wrong with your deployment setup (lack of HTTPS could definitely be the culprit as Mnemonic Flow said)
how do i send device token from my native iphone app with a specific timer request so that after the specified time push notification alert comes to device.
The title of your question and the text of it don't exactly match.
The easiest way to set up a timer request for push is to sign up with a push service provider that offers timed requests (UrbanAirship does but you may also want to check others like iLime or push.io).
The other option is to write a server where you can queue the requests then run a cron job to push them out. Obviously, that'll take more work. To actually post the message, you could use something like ASIHTTPRequest.
You may also want to tell your users not to rely on exact timing. A lot of variables enter into the process especially if user is on WiFi.