Is it possible to workflow webhook to an API service, then take the response and trigger another action to update a record with that response?
AppSheet does not provide any tools to handle the response of a POST/PUT/DELETE. And there is no GET request.
In other words, you can send data with webhooks, but not retrieve anything.
Workaround # 1 - Custom Apps Script
There’s a great post by @LeventK about getting started with Apps Script. You could write a script to send the webhook for you and capture the response, then write it back to the sheet.
Workaround # 2 - Integromat/Zapier/Etc
Use a 3rd party automation tool to send the webhook, capture the response and write it back to the sheet.
Workaround # 3 - Create a webhook in the other service to respond back to AppSheet
Many web services that accept incoming webhooks also have a tool to create/trigger outgoing webhooks. See if you can set up a response webhook in the other service, to send data back to that row in AppSheet.
This is by far the easiest, but it requires the other service to also have a webhook tool.
That’s what I feared…
I’ll just stick with integromat for now…
@GreenFlux thanks for posting, I appreciate your insight!
Glad to help, @Grant_Stead!
I could have sworn I remembered voting for this feature but I can’t find a related feature request. I guess it’s time we requested it!
Now it’s a feature request.
I have one vote left.
One vote left?
There’s a limit on how many Feature Requests you can vote for (per quarter, I think).
When you go to click the Vote button it will tell you how many you have left.
Found it. Guess I wasn’t near the limit enough.
What do you think of using Open API specs as data sources. This would help onboard your backend APIs as a data sources in appsheet.
Getting a response would be awesome…
AWESOME! This will be a game-changer!
It will eliminate the need for many 3rd party integrations, and open up lots of new options for integrating with other services.
The OpenAPI spec sounds good. I’ve integrated with plenty of APIs but never designed one, so I’m not sure, but the spec looks familiar and easy to use.
Would it be possible to dynamically create a new template variable to store the response during the workflow execution?
Something like <<WORKFLOWACTIONNAME_RESPONSE>> (<< POST Webhook_RESPONSE >>)
Then we could parse the response and extract a value from <<WORKFLOWACTION_RESPONSE>> in a subsequent step, and set the value to a column as the last step.
Also, are there any JSON parsing tools in the works? Something to extract a value from a path, retrieve a list of keys, or set/substitute a value at a path, etc?
Thanks for all your work on this, AppSheet devs!
I can’t wait, but I know this is a ton of work. I’m just glad to know that some kind of response handling is in the pipeline.
@GreenFlux - The issue is that WebHooks are asynchronous by nature…it’s kind of like “Fire and Forget”, as the thread that is invoking the http request doesn’t wait for a response. The feature that @Harsh_Ch mentioned will essentially provide a new kind of connector (OpenAPI Spec based REST connector) that is able to handle the synchronous interaction and it will be able to wait for the response and return it back to your workflow. And finally, we are re-working all of the workflow capabilities, and this will give you much better control over being able to do things like invoke APIs and wait for responses…pretty exciting stuff coming up, but it all takes time :). If you want to send me your specific use cases offline, I’d love to check them out and see if they will work well in the new feature sets. Email to : email@example.com
Thanks @Scott_Haaland! This sounds like an awesome update!
I’d be glad to send you some use cases. I’ll type up a few and send them out later today.
I would love to send an SMS, and catch a response…
How about that? Respond YES to confirm your appointment.
You know, while we’re shooting for the stars…
Would this be SMS through Twilio or what would your provider typically be for SMS? What if you could do the same with Google Chat or Slack? Would that be better than SMS, or is SMS the preference?
Thanks @GreenFlux , I received your use cases. Great stuff. Thanks for sharing.
I think SMS is preferential because it works with pretty much anyone that has a cell number. I think that being no-code I don’t really care where and how the services are connected so long as Appsheet could demonstrate a path that we could take to achieve it.