Skip to content
datarelix.ai docs

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. 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) 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 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.

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.

API keys

Programmatic access uses an X-API-Key header:

Terminal window
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 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, Kusto, and Databricks.

  • REST API reference — the endpoints these credentials open.
  • Error codes — including the plan and quota responses.
  • Security — where credentials are stored and what reaches the model.
Privacy