Authentication

AllyOneCRM has two credential models, for two different uses: user session (product/dashboard) and server-to-server integration (API).

User session — JWT

Used by the web application itself and by any client that needs to act as a logged-in user.

Creates the tenant and the first user in a single call — there is no manual approval step to start testing.

{
  "accessToken": "eyJhbGciOiJIUzI1NiIs...",
  "refreshToken": "9f2c9e7a-...",
  "tenant": { "id": "...", "name": "..." },
  "user": { "id": "...", "email": "...", "role": "owner" }
}

Send the token on every authenticated call:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

• HS256 algorithm, expires in 4 hours.
• The payload contains userId, tenantId and role — the tenant is always resolved from the token, never from a loose header.
• refreshToken is an opaque UUID with a sliding 24h TTL — each use renews the window.

Server-to-server integration — API Key

To call the API from your backend, with no logged-in user behind it.

Only the tenant's owner creates keys. The key is shown in plain text only once, at creation — the backend stores only its hash (SHA-256). If you lose the value, you need to generate a new one.

crm_live_3f9a1c...  (prefix + 64 hex characters)

Use it in the header on every call:

X-API-Key: crm_live_3f9a1c...

Scope

Every key carries an explicit list of permissions, for example:

Or ["*"] for unrestricted access — a conscious choice by the owner at creation, never the implicit default. To adjust permissions without invalidating the existing key: