How to authenticate

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

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:

The top row in the request header carries the bearer token. It is greyed out because it has been added in the Authorization tab (left of the Headers tab) and Postman automatically adds it to the header.

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