× Docs Platform Dashboard Extensions Applications Building Merchants Sign in


The platform uses a token-based HTTP Authentication scheme. A token is required to access API endpoints that require an authenticated user. Each token can be seen as a representation of a user session in the system. They are unique and private identifiers and should never be exposed to anyone besides their owners as they provide full access to a user’s account (and all Rehive features they have access to).

Once a user has logged in and received a token, each subsequent request should include the token in the HTTP Authorization header. Tokens expire 10 hours after creation unless a custom session duration is set. Once a token has expired, the user will need to re-authenticate via the login endpoint to create a new token.

Multiple active tokens (sessions) can exist for a single user. This means that a user can be logged into multiple devices (or applications) simultaneously. If multi-factor authentication is enabled for a user, the token will be unusable until all multi-factor challenges are completed successfully.


The platform provides an anonymous user login endpoint that can be used to authenticate a user:

  • /3/auth/login/

This endpoint is only intended for use in client-side code and is best used in a browser-like context due to the additional protections applied to it. These protections include severe anti-bot rules that may make it difficult to use the endpoint in a server-side context where it can be hard to distinguish between automated access and malicious actors.

In addition, in order to get around the above-mentioned difficulties, Rehive includes an admin authenticated login endpoint. The admin authenticated endpoint is intended for use in a machine-user context such as on a backend server where you can safely store an API token with admin section access.

  • /3/admin/auth/login/

When invoking the “admin authenticated” login endpoint, an Authorization header (discussed below) containing an API token must be included in the request. The API token should belong to an admin user or a user with at least the “Admin User Add” permision. By including an API token belonging to a user with admin access the request can bypass the anonymous user protections that would normally trigger firewall rules.

Authorization header

When making requests, an API key should be included as a token in the Authorization header:

Authorization: Token {token}