---
title: "Authentication & API Keys"
description: "How sign-in works on Datarelix: email and password accounts, browser sessions, API keys issued on request, and per-user database identity."
canonical: https://docs.datarelix.ai/api/auth/
---

# Authentication & API Keys

Datarelix has three separate layers of auth. They answer different questions, and most people only ever meet the first one.

1. **Account sign-in** — email and password, in the browser. This is how you use the app.
2. **API key** — an optional header for programmatic access. Issued on request; there is no self-serve key generation yet.
3. **Per-user database identity** — On-Behalf-Of for Azure SQL/Synapse, Databricks, and Kusto, so a query runs as *you* against the database.

## Email and password (the way in)

Go to [app.datarelix.ai](https://app.datarelix.ai). The page opens on **Create your account**:

- **Full name**
- **Work email**
- **Password** — minimum 8 characters, entered twice

Creating the account signs you in immediately and starts a session. A confirmation email is sent to the address you gave, but confirming it is not a gate: nothing in the product waits on it.

Returning users switch the form to **Sign in** with the same email and password.

### Forgotten passwords

**Forgot password?** on the sign-in form (or [app.datarelix.ai/reset-password](https://app.datarelix.ai/reset-password)) asks for your email and sends a reset link. Notes worth knowing:

- The response is identical whether or not an account exists for that address — that is deliberate, so the form can't be used to discover who has an account.
- Reset links are valid for **1 hour** and can be used **once**.
- Completing a reset also confirms your email address (you proved you can read the mailbox) and **signs out every other session**, so you'll re-enter your password anywhere else you were signed in.
- Requests are throttled per email address and per IP. Repeated attempts still return the same success response; they just stop sending mail.

If a reset email doesn't arrive, [contact us](https://datarelix.ai/contact/) rather than retrying repeatedly.

### Sessions

Signing in sets an HttpOnly session cookie plus a refresh cookie — no token for you to store or paste. The session is refreshed as you use the app, and `POST /auth/logout` clears both cookies and revokes the refresh token.

Because the browser session is itself an accepted credential, **you do not need an API key to use the app**. Every in-app request is authorized by the session cookie.

## Single sign-on

You can sign in with **Google**, **Microsoft**, or email and password. The sign-in page only offers the providers that are actually configured, so the buttons you see are the ones available to you.

Tenant allowlisting and other workspace-level SSO controls are part of an Enterprise arrangement: [talk to us](https://datarelix.ai/contact/).

## Google sign-in and BigQuery are separate grants

Signing in with Google authorizes **identity only** — your name, email address and profile picture. It gives Datarelix no access to any of your data in Google Cloud, and signing in is never a route to your BigQuery data.

Authorizing BigQuery is a deliberate, separate step you take in the connection form, and it applies to that one connection. You will always see a Google consent screen the first time you create a BigQuery connection, whether or not you signed in with Google. See the [BigQuery guide](/guides/connections/bigquery/).

## API keys

Programmatic access uses an `X-API-Key` header:

```bash
curl -H "X-API-Key: $DATARELIX_API_KEY" https://app.datarelix.ai/api/v1/connections
```

**API keys are issued by Datarelix on request.** There is no key-management screen in the app, no per-user key issuance, and no rotation UI. If you want programmatic access, [contact us](https://datarelix.ai/contact/) and we'll arrange it.

Behaviour when you do have a key:

- A request with **no session and no key** is rejected with `401`.
- A request with a **key that isn't recognised** is rejected with `403` — an invalid key never silently falls through to session auth.
- When a request carries **both** a session cookie and a key, the session identity wins: the account that owns the data is the signed-in user.

Treat a key like a password. Don't put it in client-side code — it is a server-to-server credential.

## Per-user database identity (OBO)

For Azure SQL/Synapse, Databricks, and Kusto, a connection can authenticate to the database as the signed-in user instead of as one shared service principal. The connection then inherits that person's database permissions exactly — no shared credential, and nothing granted in Datarelix that the database hasn't granted them.

This requires federated sign-in through Microsoft Entra and an app registration with delegated permissions to the target database, so it goes with an Enterprise arrangement rather than a self-serve setup. The customer-side registration and grants are documented per engine: [Azure SQL / Synapse](/guides/connections/azure-sql/#entra-obo), [Kusto](/guides/connections/kusto/#entra-obo-default), and [Databricks](/guides/connections/databricks/#federated-jwt-sso).

## Related

- [REST API reference](/api/rest/) — the endpoints these credentials open.
- [Error codes](/api/errors/) — including the plan and quota responses.
- [Security](/guides/security/) — where credentials are stored and what reaches the model.