We just added a small addition to how you can define parameters for API endpoints. Usually, parameters should be in the body of the request, but some services sometime add a parameter in the URL. To be able to read (and use in subsequent actions) the parameter, you can check the box ‘Querystring’.
For instance, with such settings, the URL is expected to be domain.com/api/1.1/wf/test?number=3034 and “text” will be defined in the body of the request.
This feature should only be used when the service that hits your endpoint adds a parameter to the URL. Note also that if a parameter is set to be as a querystring, it will not be available in the schedule API workflow action, as in this case you can define the parameter normally.
Great.
Another improvement would be to be able to send list of data within a field (usually ‘data’) with the API Connector or when returning data from an API Endpoint.
Is this “nested fileds” feature on the roadmap ?
@nicolas_dap Nested fields would indeed be very very helpful and open up a greater range of services that could send data to an API workflow, but they create an associated need around looping, or doing some kind of workflow action for each nested item. That can probably be solved from a design standpoint – it’s similar to “schedule an API on a list” – but we can be sure there will be performance limitations.
And then there’s the problem of multiple layers within a nested list, which would get a little confusing in terms of workflows, which have a bias towards linear flows with an “only when …” statement to handle conditional tests.
The query string parameters are a big move forward though, and open the doors for some integrations that were previously impossible or required Frankenstein solutions.
No, I’m not from the Bubble team. But I’ve spent a lot of time on the forums and read other posts about capacity and reasons why user move to a dedicated plan.
One of the big factors in performance appears to be things that require loops – for example scheduled workflows, actions on lists, or CSV uploads.
Is it possible to use query string aswell as detect data. I’m failing to figure out how I can recieve my detected data and also recieve my url parameter
So, this feature is awesome. BUT, since it is now possible to create API Workflows that have no need for a BODY component, shouldn’t such API Workflows be allowed to be triggered by GET as well as POST methods?
Here is a real-world use case that drove me to drink today:
There’s no workaround for this. We need the ability to have workflow (/wf) endpoints be triggered by either method as there are some standards (like oEmbed) that require one method or the other.
That Bubble throws:
{"statusCode":405,"body":{"status":"ERROR","message":"Wrong method. Should be a post"},"args":{"bubble_code":"1537917189069x708313714247196900"}}
… if you hit such an endpoint with GET rather than POST is completely arbitrary and pointless in the context of what I’m describing above.
I have the same problem, I’m trying to find a way how to comply with oEmbed standard. And I didn’t find a solution yet. @keith, did you find any workaround? Only outside of Bubble, like Amazon API Gateway?
I haven’t gotten oembed to work yet. I did play with AAPI Gateway, and it may be possible to do all the stuff one needs there, but the scripting language is so awful… it IS effective and ez to transform gets to posts there, but that’s about the most useful thing I’ve done with it. Tried another api gateway as well without success.
I’m assuming you’ve seen my thread and replies about attempts to get oEmbed up and running. It would be SO easy in Bubble if there were a way to return custom HTTP responses.
I got really excited about this functionality than I realised that if you use the detect response feature this is not available. And of course it appears that you need to utilise the detect request date functionality to access nested fields. This makes webhooks so unusable without resorting to another hacky service like zapier to flatten your JSON. Come on guys, please add the ability to access URL parameters when using the detect response feature or atleast show us how to access parameters in a nested field.
