Webhook Content Type - Twilio API Error

[Chris_Sondesky]

Hello - after thorough searching here, there have been a few threads regarding Twilio integration with SMS, but none discussing webhooks.

Here’s the challenge:
Appsheet webhooks do not permit a content type that Twilio accepts; Twilio is looking for www-form-urlencoded, however Appsheet only does JSON (and others), and Twilio won’t accept a JSON request; it fails on a 400 error.

Has anyone found a solution to get Twilio to accept POST requests from an Appsheet Webhook?

Any insight?

[Phil]

Hi Chris,

AppSheet allows you to send SMS via your own private Twilio account.
There is direct support for doing that in the SMS workflow action.
Are you trying to something beyond that?

[Chris_Sondesky]

Hi Phil!

Yes, we’re aware of the SMS workflow action, however that poses a number of issues for us, in no particular order:

Not as robust; not scalable; not cost efficient; limitations on content; restrictive feature set on Twilio; not actually a software integration.

To further answer - yes, we are doing more than just a single, one-way text notification, and that is the need for the formatting option.

Thanks so much for your reply!!

~Chris

[Phil]

Can you clarify exactly how you picture the webhook working?

I think you are asking us to support a webhook with an “HTTP Content Type” of “x-www-form-urlencoded”. This would yield a Post body with a MIME type of “application/x-www-form-urlencoded”.

Do you have a preference about how you would specify the “Name=Value” pairs in the body?

I presume we would take responsibility for %HH encoding the non-alphanumeric bytes in the payload.

Are you aware that our webhooks simply do the Post, Delete, or other verb you specify and that you have no access to the response returned by the webservice you invoke?

[Chris_Sondesky]

Hey Phil – we picture this working by passing appsheet app data in variable form (i.e <<[CustomerID].[FirstName]>>) to Twilio for execution.

You’re correct on our request. Our preference would be to specify the name=value pairs in the body via txt template; the formatting we’re using is below and would sub appsheet variables as indicated.

Currently, we are able to successfully trigger this via Postman; here’s an example of the name=value pairs (really, it’s only to/from and parameters as detailed in the Twilio API) of how they output:

To=+1<<[ApptTextPhone]>>
From=+1<<[ClientTwilioPhone]>>
Parameters={
“customer_first_name”:"<<[CustomerID].[FirstName]>>",
“dealer_managers”:“Mike & Angelo”,
“appointment_time”:“9:45a”,
“dealer_logo”:“https://www.appsheet.com/Template/gettablefileURL?appName=V2-SMS-1023929&tableName=Dealership&fileNa...<<[CustomerID].[DealerLogo]>>”,
“dealer_directions_url”:"<<[CustomerID].[DealerDirectionsURL]>>"
}

This generates the following code, which successfully creates the POST request to Twilio.

curl -X POST
https://studio.twilio.com/v1/Flows/XXXXXXXXXXXXXXXXXXXXXXX/Executions
-H ‘Content-Type: application/x-www-form-urlencoded’
-H ‘cache-control: no-cache’
-d ‘To=%2B12672781942&From=%2B16303608863&Parameters=%7B%0A%22customer_first_name%22%3A%22Chris%22%2C%20%0A%0A%22…’ (truncated)

We don’t need to collect the response data and aren’t intending to; our workflows on the other side will generate a separate call back to appsheet for any info we need back.

Hope that helps, thanks so much for your response!

[LeventK]

@Chris_Sondesky
Instead of using AppSheet’s Twilio integration, you can build a Google Apps Script, deploy it as a webapp and use its URL as an endpoint URL for a Webhook Workflow rule and you can invoke the Twilio API. Provided your Twilio number is accepting SMS replies and you are watching the replies to pass values/replies/confirmations (or whatsoever) to your AppSheet app, you can also use the same webapp with a doPost as well. We use this method with one of our customer in NY who is a Property Manager to receive the latch codes back to the app when set by the tenant.

[Chris_Sondesky]

Hi Levent, and thanks so much for your reply! We did consider using a Google Apps Script, but that poses additional challenges. We are an AppSheet Business subscriber and will be migrating to SQL, thus we are not sticking with the Google Sheets infrastructure. The SMS functionality is only a small part of the Twilio stack in our platform.

Really appreciate you taking the time out to share that use case with us, and it’s a terrific idea and one we’ve considered as a fallback, unfortunately it doesn’t meet our intended scope and targets.

[LeventK]

@Chris_Sondesky
I do understand your situation but I haven’t imposed anything about the use of gSheet. We are on Business Plan too and we do use the MySQL as well. You can create a standalone Google Apps Script project as I have explained and push data directly to your SQL back-end. You just need to create the ODBC/JDBC connection string and that’s all. The better; provided you have AppSheet API initialized with your BP, you can directly push the data to your app with the AppSheet API and you don’t even need to mess with the ODBC/JDBC string at all. I believe both strategies above is better than a webhook workflow.

[Phil]

I have enhanced webhooks to support HTTP Content Type “FORM_URL_ENCODE”.

This will allow you to construct a webhook Body containing “Name=Value” pairs.
The Names and Values are URL encoded.
The Post is performed specifying a MIME type of “application/x-www-form-urlencoded”.

If testing goes well the enhancement will be released on Wednesday afternoon Seattle time.

[LeventK]

@Phil You’re da man!!

[Phil]

It looks like the release of this feature will be delayed until Thursday afternoon.
There were test problems unrelated to this change that will delay the deployment.