Forum Documentation Showcase Pricing Learn more

[New Feature] Ability to read parameters in the URL for API workflow endpoints


#1

Hello,

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’.

36%20PM

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.


#2

Thanks @emmanuel and Bubble team!


#3

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 ?


#4

Awesome!!! Thanks @emmanuel


#5

@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.


API workflow - URI parameter
#6

Hi @bcronin7, are you from the Bubble team for making assumptions about the issues behind the scene ?


#7

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.


#8

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


#9

@emmanuel

Is there anything on the road map for this feature to work in conjunction with “detect data”


#10

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.

Can that just be removed, please? pretty please?