Hi,
While using Twilio instant triggers today, I noticed that Twilio apparently expects some kind of specific response from the webhook in the form of “TwiML” data.
I found this out here: https://stackoverflow.com/questions/54446075/am-i-receiving-these-errors-because-my-webhook-isnt-sending-any-twiml
Can I somehow update my Twilio instant triggers to return some specific data?
Thanks,
Ben
System native webhooks, those that use the Webhooks module, currently only return HTTP status codes. This is because native webhook automation execution is asynchronous. When a webhook is received, the system first logs it, places it into the database, then sends a HTTP status code back just indicating if the webhook will be processed or not. Then the automation is placed into a work queue for eventual execution.
Will the twiml response always be the same? Or will it vary based on the incoming webhook data? Send a link to the API documentation.
I see, the asynchronous nature of the webhook response and the automation execution makes it impractical to base the webhook response on the result of the automation execution – do I have that right? I’m not sure what to say, it does look like some of the behaviors related to TwiML are pretty complicated.
I started off with this thread: https://stackoverflow.com/questions/54446075/am-i-receiving-these-errors-because-my-webhook-isnt-sending-any-twiml
And here is some documentation explaining about TwiML: https://www.twilio.com/docs/voice/twiml
An automation that invokes actions cannot send a response to an incoming webhook based on the results of its processing, due to the asynchronous processing of automations in the system’s work queue.
By itself, a unary protocol thread can send a varying response to an incoming webhook, but the response cannot be generated by an automation. The appRPC.handleReceivedUnaryProtocolPayload() method within unary protocol threads may place many automations into the work queue.
A Web Service assembly, like the Flickr web service 6b776c518b074a1b83fd6d6f0b6a7e36, can perform processing and return a response back to the caller that varies. This is currently the only mechanism in the system that could let you build an interactive Twilio VRU. The downside is that Web Services are not Automations, so all the logic would be built into the Web Service assembly in the Assembly Editor and not the Automation Editor.
Perhaps it will be possible for per-trigger protocol threads to generate a response based on the actions in its automation, since per-trigger protocol threads have a direct relationship to a single automation. This is just conjecture.
Another option that just came to mind is to have a Web Service assembly invoke an automation like is done in the “execute automation” action: 088b66532b1f4ceb89384bb0b859e9f2
Currently there is no direct mechanism to obtain the results of the execution, but I can think of ways it could be done without too much trouble.
The downside is that the web service would be hard-wired to a certain automation.
Well, this is all hypothetical, as I don’t have a use case for this currently (as I think I implied in another thread).
With your web service suggestion, would the web service also serve as the webhook ie would the process be as simple as registering an Apiant web service as a webhook address with the app? I can see that if that is the case, then the web service assembly would offer the necessary flexibility in forming the respone. Then the ability to call the “execute automation” module would get us back on track with whatever else needs to be done.
Sounds like a good approach to me, thanks!
Yes, each web service assembly has a unique URL, so they could be registered as webhook URL’s within other apps like Twilio.