I use Twilio's WhatsApp API.
Incoming messages, status updates, are sent to my server via callbacks - standard stuff.
I also use several services which ride on the same callbacks - e.g., Frontapp, Missive, and the like.
What is the best way to 'fan out' callbacks to the other services? Is making a separate HTTP post call to each of the other service, mimicking the format of Twilio's callback the best way?
Intuitively, I shouldn't be able to use HTTP redirect, because it'd only allow me to forward, and not fan out the call. Am I right?
I’d go with a simple function (e.g. Lambda, Zapier, etc.) that will:
receive the webhook from Twilio
respond ‘200’ (otherwise Twilio will try the fallback Url)
replay the payload to other listeners
Your stretch goals could include:
async delivery/retries (write the payload to a DB, listeners pickup on that write and deliver/retry their respective services, independently)
Twilio signature checks (duh)
Happy dev
Related
We have implemented a Logic app to call do a POST call to a third-party API which returns a 202 with location header. The Logic app in the backend automatically polls using the location header resulting in GET request to the third-party provider hoping to receive a 200 response once the processing is complete. However, the GET requests are resulting in 404 errors.
We have tried disabling the check location headers but for some reason Logic apps still continues to send the GET requests and at a faster rate.
Is there any way to stop the GET request from Logic Apps or should this be the third-party provider's responsibility to handle the polling and not send 404's?
Yes, you can stop the GET request from your Logic Apps. Basically it totally depends on your workflow. If you are designing a stateful workflow then I would suggest that not to stop the GET request.
For stateful workflow all HTTP-based actions follow the standard asynchronous operation pattern as the default behavior. Where after an HTTP action calls or sends a request to an endpoint or API, the receiver immediately returns a "202 ACCEPTED" response. And the response can include a location header which the caller can use to poll or check the status for the asynchronous request until the receiver stops processing and returns a "200 OK" success response or other non-202 response.
But if you are designing a stateless workflow, then caller doesn't have to wait for the request to finish processing and can continue to run the next action. In this case the receiver return the "202 ACCEPTED" response as-is, and proceed to the next step in the workflow execution. A stateless workflow won't poll the specified URI to check the status.
You can stop the GET request from your logic app by following any of the two approaches mentioned below.
Turn off Asynchronous Pattern setting.
You can achieve this by going to the Logic App Designer, on the HTTP action's title bar, selecting the ellipses (...) button and setting Asynchronous Pattern to Off if enabled.
Disable asynchronous pattern in HTTP action's JSON definition.
In the HTTP action's underlying JSON definition, add the "DisableAsyncPattern" operation option to the action's definition so that the action follows the synchronous operation pattern. Check this document for more information.
Also check this Asynchronous request-response behavior document by Microsoft for more understanding.
We have an existing set of applications that use Urban Airship for notifications. We want to automate the testing of the server component.
We use automated testing as far as possible. Specifically, I want to be able to validate that when I make a /api/post call for a specific tag, then Urban Airship generates a notification for that tag.
In an ideal world, I'd make a web REST call along the lines of 'return when notification received for tag=XXX or timeout', and validate that the response was what I expected.
Does such a call exist, or can anyone suggest another approach other than including phone hardware?
Charles
There's no end to end callback for any push service since it goes through a variety of other services (APNS, GCM). In other words, you can't do an HTTP request to Urban Airship, then have a call back when the notification is received on the device. The best that you could do, is use Urban Airship's API to do a post call to send the message, then check that the response is a 2XX response. The 2XX response doesn't indicate that the push was received on the device, but it at least validates that UA has received the request to try and send that notification.
Another option that you could look into is using a service such as appthwack: https://appthwack.com/ I'm not sure if they are able to test push notifications, as it looks like they use emulators, but it's worth looking into imo.
I need to call the desk.com api to create cases when a customer completes a form on my site. However sometimes the API is down for maintenance (too often!) and my call will fail.
Presently I just write the details to a log on error and send myself an email. Then I create the case manually.
So I'm thinking to write some kind of message queue so instead of calling the api in-process, I can put the request in queue, then have some process work the queue and make the api calls. they way if the api call fails the process will just try again next scheduled interval.
Since there are so many web APIs in the world, I figure surely other people must be having the same problem. So are there some third-party solutions which effectively do what I'm trying to do? or some open-source project or something to deal with this issue?
Cheers!
Amazon Simple Queue Service (SQS) is a fast, reliable, scalable, fully managed queue service. SQS makes it simple and cost-effective to decouple the components of a cloud application. You can use SQS to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available.
http://aws.amazon.com/sqs/
If a call is incoming when using a Client Browser (twilio.js) and I am already connected to an active call in the Client Browser. Client Browser doesn't ring or given any indication of an incoming call while I'm already on a call with someone else.
Is this a bug? What can be done about it so I can tell if there is an incoming call? I need to be able to answer that 2nd, 3rd, 4th, etc... incoming call should I have multiple people calling my Twilio number at the same time.
Kind of a late reply but you can use the Enqueue verb to place your callers in a queue, and then use the REST API with a javascript setInterval to list the callers in the queue. After that you can dequeue them with a Dial method or via the REST API.
We have crafted call-center functionality in node using a similar method where callers are placed in a queue which triggers a setInterval loop that monitors the queue for its members, and also looks for available agents to call.
For anyone interested I have solved this problem for myself, but in a different way to what #Ding suggests.
I'm not sure if the API has changed since this questions but you are able to access multiple Connections from a single Twilio.Device(). See this question for more details: Twilio call routing/management for small customer service team
I'm writing an API which is used to receive some data from another application. Currently the function is designed to block until data is received. In my mind this limits developers using the API to use multithreading or some sort of multi-process design. So is it better for a function to block or to return a null and then sleep for a few milliseconds before trying again.
Note the other application may not have any data to send through the API for an unknown period of time.
The API is written in C++
Why not use a callback?
You could define the API to allow the user to pass an optional timeout value. If the timeout is not specified, then the API function waits indefinitely, much like how select() works.
Consider another option: use an async transaction -> issue a request & provide a callback address with ticket id. When the response is available, the service end-point callbacks your application with the ticket id and of your the result ;-)
You should avoid as must as possible blocking when you possibly can.
As you say:
Note the other application may not have any data to send through the API for an unknown period of time.
In this case, using a synchronous interface ties up resources unnecessarily.
You haven't said what language this is, but it sounds like your API is listening or checking for some event, and the users of the API are either blocking or polling your API to determine if the event happened?
Is it possible to use a callback? Users of the API would register for notifications of the event happening, and when your library detects the event it will use the callback to notify all listeners.
When your applications calls the O/S api function read(), do you expect it to block? Of course you do—at least by default. In some circumstances, ioctl's allow a programmer to change the behavior to be asynchronous, which is particularly common in network applications.
You've shed very little light on what your API is about, so consider:
Does it make sense that an API user would want to be blocked? That is, is there little to do until it returns.
If you were writing an application for the API, what would you expect it to do? You should definitely write a few sample applications for your own education, as well as to document the API.
Is there any reason why the API user would not multithread (or fork, etc.) requests to the API?
If you want a reusable solution you could apply the Asynchronous Design 'Pattern' which is common in .NET but can also be implemented in C++ as demonstrated in this CodeProject project.
There's nothing wrong with providing both synchronous and asynchronous calls to the same feature in the interface.
Personally I would only go these lengths if I need to service multiple requests (in which case you can queue 'BeginOperation' requests for example), or there are many potentially asynchronous operations in the interface (and I want a standardised, flexible pattern). If you can only handle one request at a time a time-out is usually sufficient.