Trigger API Workflows with GET Requests

[peter.wu]

Hello everyone!

My name is Peter, and I am a software engineering intern here at Bubble. Users have asked for the ability to allow API Workflows to be triggered via GET request instead of the usual POST request for a while now. A powerful use case for building logic around a GET request would be in the case of Bubble app listening for a 3rd party (e.g. Facebook) webhook. We’re excited to release this ability today on our experimental flags panel, and it will soon be deployed once it’s well-tested.

For the full documentation on the feature, check it out here: https://manual.bubble.io/core-resources/api/workflow-api

Overview

Today, as a user on a Personal plan or above, when you select the Backend Workflows tab on the top left, your API Workflow looks something like this.

Now, you have the ability to select between GET and POST to trigger your API Workflow, as shown below, using the new “Trigger workflow with” dropdown menu option. When you hover over this option, it’ll take you directly to the documentation.

How to Use It

As you can do today, if you select to trigger the API Workflow with a POST method, you can choose “Manual Definition” or “Detect Request Data” for the parameter definition. Otherwise, if you select to trigger the API Workflow with a GET request, the parameter definition will default to “Manual Definition,” and the field will be hidden. You can still define key-value pairs as normal.

If you are using API workflows via the App Connector, these workflows will automatically be triggered by the proper HTTP request defined in “Trigger workflow with” dropdown.

Backwards Compatibility

When you switch between GET and POST, the definitions and parameters you’ve defined will be preserved. The contents for “Detect request data” will be saved if you decide to switch between the different options of “Parameter Definition.” Our issue checker will ensure the data is correctly formatted and expected, and there’s no change on what you can expect here.

This feature has been long requested, and we’ve definitely heard your feedback. Thanks so much for your ideas along the way — they were instrumental in helping us develop the feature. Let us know what you think

[J805]

@peter.wu That sounds great. Looking forward to using it in the future. Is there a way to save the data that is detected as a text field or be able to save the whole thing as a dataType from a webhook yet? It’s annoying to have to save each field independently and there are so many cases that I need this ability. Would this be possible?

[johnny]

This looks great! Will for sure try it out. It’s nice to see the Bubble team shipping a ton of new features!

[ihsanzainal84]

Niace! This will work great for advanced Telegram and Slack workflows!

[einieini]

I’ve been scouring through the forums searching for a solution to the EXACT scenario you’re presenting! to no avail… Peter, thank you!

I’m curious. Did you specifically try Facebook’s Webhook flow? I’m facing a strange behavior.

When a GET request to my Bubble’s endpoint is initiated by Facebook’s Webhook Verification tool, Bubble’s server initiates the flow and parses the challenge token as expected, but their server parses the API-returned key/value as empty. This is where things get weird: If that “Return Data in the API” Key-Value section is hard-coded (i.e. type in arbitrary string for testing the connection -as opposed to using the Dynamic Data), Facebook’s servers do receive the value as typed, albeit doesn’t verify because it is not the actual dinamically-generated token.

In other words, if I try to return the challenge token by way of a Dynamic Data variable retrieved from the GET request, FB gets an empty string, but if that value is typed in, FB receives exactly what I typed.

Gets weirder. If I emulate that same GET request from FB to my Bubble’s endpoint via Postman, Bubble’s functionality does work as expected and I do get back the supposed challenge token included in the query string FB sends.

Any thoughts?

EDIT: it all comes down to Bubble not allowing period (.) in the Key - care to explain? other spl chars are allowed…now I have to set up a server somewhere else just bc Bubble wont allow periods.

[buero]

image do not load in this post? tried in serveral browsers

[NigelG]

Images would be nice. But this is awesome.

[ryanck]

Hey @NigelG

Do you mind explaining why is this awesome? What’s the use case?

Thanks man

[lottemint.md]

[helder]

Receiving emails like this are truly awesome…
Specially for a feature like this

[jizreel_alencar]

Hi, thanks for launching this feature. It would be awesome if we could receive access tokens in the headers as well. I’ve tried to send an access token to an endpoint that was set to “Detect Request Data”, it worked, but when I performed another call to the endpoint using a different access token, it didn’t work, I think bubble engine didn’t left this field dynamic.
Plus, having the other methods DELETE and PUT/PATCH soon would be much appreciated as well, that way we could have a Restful API for our application. Thank you again.

[NigelG]

@ryanck

Do you mind explaining why is this awesome? What’s the use case?

Sure.

So, usually “web hooks” are set up in external applications so that “when this thing happens” you get a trigger in your app. It is a lot simpler than polling every x minutes to ask is something has happened yet.

For example, in Stripe you set up a Webhook on Payment Success - “tell me when a payment has been made”.

In Bubble we do that via a Backend API workflow being external. So we give Stripe the URL of our API workflow and then it gets triggered. Workflow runs by something outside of Bubble. Can be VERY powerful.

In the case of Stripe, it does a POST to our URL. POST is like a “here do this”.

However, there are webhooks that want to do a GET to our URL. This really “should” not be a problem but Bubble only allows POST. So it has always been impossible to do natively.

We CAN have a GET on a DATA URL - but that is not really the same use case. We want to do some processing.

It was possible to turn the GET into a POST in AWS or Integromat.

Things like Instagram want to do a GET on your endpoint. No idea why.

Also, you might want to offer a GET service to external users. So they can query things that are beyond just a “get row from table”.

So … it is awesome because it really always should have been there.

And it allows us to offer really quite a full REST API implementation to customers. Which is pretty hardcore for no-code.

[grace.hong]

Hi all - chiming here with a few responses

@buero @NigelG - Images should be updated now!

@J805 - I don’t believe we have that feature yet. Just so I understand correctly, when you mention the data that’s detected, are you referring to the data detected as a result of triggering an API Workflow with a GET request or something else?

@einieini - Thank you for sharing this particular feedback! To clarify, is the problem that Bubble does not allow you to enter periods as part of the name for the key field when entering manual parameters, or is it for the key field when you use “Detect request data”?

@jizreel_alencar Thanks for sharing this feedback - noting this down for the Product team.

[einieini]

Hello @grace.hong ! the problem is that Bubble does NOT allow to enter period(.) as part of the name for the key field. In Meta’s verification webhooks, many many parameters use period in the key.

E.g. Getting Started - Webhooks - Documentation - Facebook for Developers

Thanks for taking the time to help out!

[J805]

@grace.hong

@J805 - I don’t believe we have that feature yet. Just so I understand correctly, when you mention the data that’s detected, are you referring to the data detected as a result of triggering an API Workflow with a GET request or something else?

Hey @grace.hong

Thanks for responding. I’m talking about a webhook that we are receiving into the backend workflow. It would be great to save all the data in one field instead of breaking out each data field one at a time. When there are a lot of fields, it takes forever. To be able to save it as JSON would be awesome.

[ryanck]

Thanks a lot for the detailed explanation @NigelG. Good one for sure.

[stageme]

I subscribe to this, was just checking how can I convert GET to POST for Bubble ingestion.

[NigelG]

@J805

Thanks for responding. I’m talking about a webhook that we are receiving into the backend workflow. It would be great to save all the data in one field instead of breaking out each data field one at a time. When there is a lot of fields, it takes forever. To be able to save it as JSON would be awesome.

This would be so useful. +1

[NigelG]

@einieini

the problem is that Bubble does NOT allow to enter period(.) as part of the name for the key field

But it does in the API Connector user id field. You can drill down in the JSON to get to the field you want. So there is precendent, have a look at how that works. You can also (if my memory is good enough) do arrays like [0] to get the first in the list etc.

[NigelG]

@jizreel_alencar

Plus, having the other methods DELETE and PUT/PATCH soon would be much appreciated as well, that way we could have a Restful API for our application.

Totally agree.

REST APIs should really be about resources. But resources <> your database tables.

Being able to abstract away from your database would be amazing.