Build a Rest API

Need help
1

Is it possible to build a Rest API for my bubble app that I could then licence out?

2

Can you elaborate? license out to who, your own customers?

3

Yes every backend workflow you make allows for “Expose as public endpoint” (or something like that)

Then you can do whatever processing you want in the workflow, then use the “Return data from API” action to return back what you want.

Probably would want some kind of API KEY datatype, each user generates their API KEY, and each workflow would search the database and make sure the API key is there to authenticate.

And maybe another datatype “Request” that logs every single request, then that also allows for asynchronous requests, so they can do a POST request and it responds with the unique ID, and later your app can send a webhook to a URL of their choice, with the Request unique id as the reference

1 Like
4

One important thing that bubble doesn’t handle tok well yet is privacy right on API calls. You can’t even see which key is in use. There are some workarounds but none are “clean.” That’s why @micheal.killarney I asked for more info on use case.

1 Like
5

This is absolutely NOT how you want to handle it. To verify an API key is valid with this method you must leave “API key database” public. Which means anyone can access list of keys. You’d also have to verify the user connected to the key which means users would be partly public which can cause DB dumps by bad actors.

Rather you need to use bubbles recommended way of doing this. Create a backend workflow called /auth no authentication needed. The only step here is “log the user in”. 2 fields passed email & pass

Your API user will pass email/pass to this call and it’ll either deny or accept the server side login.

If accepted it returns a basic auth bearer token you will pass in the header of every other API call. That will authenticate. This also attributes everything to “current user”.

If remember me is checked on login action it’s a 1 yr token. If it’s unchecked it’s 24 hr token expire.

To revoke access you will have a /revoke call with a “log the user out” which expires the key.

This will maintain all privacy rules, authentication, and security of your app.

If you want you can have a second “security” token stored on the user since it’s already authenticated to allow for a bit better attribution of where calls are coming from, logging, or API usage limits. Not necessary though.

Sometimes bubble does expire keys sooner than the expected date so your API user will want to have an error handler that will /auth again if they’re getting an expired token response. However, that’s not all that abnormal.

A lot of other apps (hubspot for example I believe) use this same method. Which is why once a year you get an email from them to login and regenerate your API key. While logged into your dashboard when you click “generate new api key” it actually hits the server to create a new basic auth key which your user then saves but the db only saves the end of the key or an encrypted version of the key. So your /auth call doesn’t technically have to be from the server side by your user.

@code-escapee no work around needed. Do this ^^^ :wink:

I highly recommend anyone who is a serious developer on bubble to sit down and spend a few hours a day for a few days reading the entirety of the bubble manual and test implementing a few things via best practices.

You’d be surprised how many “amazing” bubble developers and even agency developers don’t know some of the basics of bubble docs & best practices.

7 Likes
7

Good info :+1: :100: , thanks for correction on my bad idea :rofl:

2 Likes
8

Great stuff Chris!

Bookmarked :+1:

1 Like
9

Chris, thanks for providing such a clear and detailed solution.
Quick question - is there any concern with having a endpoint not requiring authentication in terms of it getting spammed constantly?

Yes you are right. Just waiting for @petter to finsih his updates and hopefully Bubble will provide a pdf of entire manual to print and go thru…

1 Like
10

That’s a risk with anything. Even if it’s authenticated they could spam it and cost you WU on the unauth responses. Honestly not sure how to handle it outside of maybe IP checks vs logging but any bad actor can get around that so easy.

I don’t typically keep much unauthenticated outside of the /auth and /revoke flows.

11

This topic was automatically closed after 70 days. New replies are no longer allowed.