Handle with 'dev' and 'live' environments using 'API connector' calls

One year ago, I set up the API connector with different calls to my ‘dev’ backend. Then, I wanted to do the same for my ‘live’ environment backend, where there is a minimal change in the URL (changing ‘dev’ for ‘live’ prefix). At that time I was in a hurry doing a lot of stuff, so I just did a quick search in Bubble Forum and the answer was ‘duplicate API calls’. So I just did it, but I annotate a future work to my board for handling this situation better, being able to have just one API call set being able to parametrize the API calls.

So time arrived, and last week I took the challenge. After doing some tests, my workaround worked. The trick is to parametrize each API call with a parameter indicating the environment prefix. In my case:

As you can see here, I defined ‘envPrefix’ as a parameter of the call. Then, I’ve also defined an ‘Option Set’ in Bubble Data in order to have the constant definition of url prefixes depending on live/dev environment:

Finally, when I call the defined API call from my Bubble pages, I use the ‘isn’t live version’ formatted as text in conjunction with the created ‘BackendEnvironment’ option set for selecting the environment prefix of the URL to call.
2020-12-21 10_19_07-Opground _ Bubble Editor

BTW, this trick is also useful for dealing with API calls defined in the same Bubble server as backend workflows (if you need to retrieve some data after calling the workflow), so you can define an API call once. In this case, the defined Option Set could be something like:

Let me know if it has been useful to you! :slight_smile:

27 Likes

Excellent, very useful, thank you ! :+1:

2 Likes

This is smart.

I’ve seen plugins with live and dev inputs, is this something only available by coding or is it just a setting?

My steps would be to convert my api connections into a plugin and then access this plugin from the app

Really clever and elegant solution. I’d set up the parameters but had additional steps to only run when the environment was dev or test, this is much cleaner thank you!

Top tip :+1: :+1: :+1: kudos - but wouldn’t it be much simpler if Bubble exposed shared variables (like param) so we could use that in the URL or path in the API connector. Oh well. :slight_smile:

Yeah spot on - this is the best solve. No coding required - easily done; How to handle development/staging APIs with Bubble?

1 Like

this is excellent - thank you!

I have just had this same issue regarding an API payment solution.

I was using a fixed webhook typed in text i.e
https://appname.bubbleapps.io/version-test//api/1.1/wf/endpoint_example
https://appname.bubbleapps.io/version-live//api/1.1/wf/endpoint_example

But I had to remember to change it every time I re deployed my app to the live version for it to work.

To get around this, all I did was change it using the “isn’t live version” option to:

https://appname.bubbleapps.io/version-isn’t live version is “yes”:formatted as text/api/1.1/wf/endpoint_example

In the yes box used: test
In the the no box used: live

It worked like a charm, and I didn’t have to set up any attributes or options.

This was used for a POST API call to a third-party payment gateway, and the workflow was set up in the backend to detect the response.

This was a game-changer that solved a huge problem we had in our dev-to-production pipeline. Huge thanks! :pray: