How to authenticate

This section covers what kind of authentication method the Bubble API accepts.

Help us improve this article

This article is part of a significant update to the Bubble manual and your feedback is critical to our efforts to continuously enhance our written documentation. We would greatly appreciate if you could take a moment to let us know your thoughts on the quality of it. Thank you for your support! Give feedback on this article

This section covers what kind of authentication method you can use when you are making an incoming request to to your Bubble application from an external app.

If you are looking for how to authenticate outgoing requests sent via the API Connector, check out this article.

Bubble's authentication method

There are many different ways to an API request. Bubble uses the method known as bearer token.

What is a bearer token?

The bearer token is a string that identifies who the client is. It serves as both username and password and is included in the header of the API request. Tokens are generated by Bubble by creating an or by .

Since every request is made independently of any previous or later requests, the token needs to be included with every API request coming into your app that requires authentication.

Authenticate with a bearer token in Postman

The bearer token needs to be included in the Authorization header of an HTTP request, in the following format:

Authorization: Bearer <token>

In the example above, <token> represents the actual token string. Do not include "<" and ">" in the final string.

In an application like , the authorization should look like this:

When included like in the above illustration, Bubble will recognize the token and respond to the call according to the privileges (if any) of the User that the token represents.

How secure are API bearer tokens?

Bearer tokens are considered more secure than sending a username and password in each request because they can be easily revoked, have a limited lifetime and can be connected to one of your app's Users which allows you to limit the scope of their database and workflow access by use of and .

Additionally, bearer tokens can be easily revoked if the user's device is lost or stolen, whereas revoking a password would require the user to reset it on all devices. Additionally, tokens are sent in the headers, which are less prone to being intercepted than cookies or URL parameters. Tokens generated by Bubble are considered , meaning they cannot be easily reconstructed and have a length of 32 bytes. Article: Revoking a User token Article: Revoking an admin token

Last updated

#686: Updates to SAWOL

Change request updated