This Product Ideas board is currently undergoing updates, but please continue to submit your ideas.
I hesitate to make suggestions here, because of how even the most popular and basic requests have yet to be implemented, but I will anyway.
I would like to be able to execute an HTTP request against values in other fields. This is possible in Excel and would be just as valuable here.
The most basic implementation would use the GET method where I would define the URL and querystring separately.
Yes, this would be an advanced feature that would generate support requests. Perhaps it could be hidden behind an Advanced Features toggle in a workspace’s or base’s settings.
I’ll second this request - I also need this type of feature. My use case is:
Anything new in this topic?
But it may also reduce many support requests. Here’s why…
If you scan this forum paying close attention to the patterns that cause users to employ complicated workarounds to do things that are generally possible and simple in other tools, there is one pattern that seems to tower over all others.
The need to craft computations and plug the outputs into records/fields that are based on arbitrary logic - specifically scripts.
@Chris_Parker described a good example - call out to a service that can receive two values, concatenate them, and return the result into the field where the call was made from.
Another good one is a question I see repeatedly - how do you iterate across a bunch of records and then update one record with a computed value dependent on multiple records?
Lastly, imagine a customer feedback comment field and the need to perform sentiment analysis. With HTTP integration, the sentiment field could simply call to an AI algorithm at Algoriythmia passing it the comment field and returning the result.
This requires a field that has two elements - (i) the http request (i.e., no different than a formula), and (ii) the value (i.e., the response of the request). Formula fields [apparently] already do this, but what they don’t allow is a formula that represents an open web standard - and HTTP request. It’s literally one more function type.
By using HTTP requests, Airtable solution experts could extend the platform to leverage all sorts of stuff that currently reside outside the walls of Airtable. I believe the ability to seamlessly embed HTTP requests will vastly reduce the common and sometimes difficult work of finding alternative approaches to enhancing data in Airtable.