Access tokens

How people and applications authenticate to an e6data workspace with access tokens - the credential types, what they carry, and how token auth relates to RBAC.

This section explains how people and applications authenticate to an e6data workspace for programmatic access - creating tokens, using them, setting an expiry, rotating them, and the security practices around them.

e6data uses token-based authentication for everything that talks to a workspace over the API: BI tools, notebooks, scripts, CI/CD pipelines, and backend services. A token proves who (or what) is making a request. It does not carry permissions of its own - what a token is allowed to do comes entirely from the roles and permissions bound to its owner.

Tokens are scoped to a single workspace. You need access to a workspace in the e6data Console before you can create one.

Token types

This table is the canonical reference for e6data credential types. Other pages link here rather than redefining them.

Type	Prefix	Identity it carries	Where you create it
Personal Access Token (PAT)	e6pat_	A human user - your own account (your email)	Avatar menu → User settings → Access tokens
Service Account API key	e6sa_	A service account - a machine identity, scoped to one workspace	Administration → Service Accounts → [account] → API Keys

• Use a Personal Access Token when a human is the actor - for example, connecting Tableau under your own identity, or running a notebook.
• Use a Service Account API key when a machine or automated process is the actor - CI/CD, Airflow, dbt, or backend services.
• "API credentials" is not a separate thing in e6data - it is just a casual umbrella term. Whenever a tool asks for "API credentials," "an API key," or "a token," you supply one of the values above.

Never put a PAT in a shared pipeline or CI system. A PAT is tied to your personal account; if you change roles or leave, it stops working and the pipeline breaks. Use a service account for automation.

PATs and service account keys are covered in Personal access tokens and service account keys.

Key concepts

Term	Meaning
Workspace-scoped	The workspace is baked into every token. A token issued for one workspace is not valid in another.
Identity, not permissions	A token has no inline permissions. It only says who you are. All access is decided by role bindings on the user or service account. To restrict what a token can do, change the role binding - not the token.
Shown once	The full token value is displayed only once, at creation. It cannot be retrieved again. Lose it and you must create a new one.
Expiry (optional)	A token can have an expiry, entered in days (default 90, maximum 3650), or be set to never expire. Expiry is enforced on every request.
Rotation	Replacing a token before it expires or after possible exposure to avoid downtime.
Revocation	Invalidating a token immediately. Revoked tokens stop working at once.

How token authentication works

e6data separates who you are (authentication, proven by the token) from what you can do (authorization, decided by role bindings). Every API request runs the same path:

1. The client sends the token in an Authorization: Bearer or X-API-Key header.
2. e6data validates the token and checks its expiry. An expired or malformed token returns 401 Unauthorized.
3. The token resolves to an identity - a user or service account.
4. e6data checks that identity's role bindings in the workspace. If a binding allows the requested action, the request runs (200); if not, it returns 403 Forbidden.

A perfectly valid token still returns 403 if its owner has no role binding for what it is trying to do.

Where to find things in the Console

To manage…	Go to
Your own access tokens (PATs)	Avatar (top-right) → User settings → Access tokens
Service accounts and their API keys	Left sidebar → Administration → Service Accounts

See also

• Personal access tokens and service account keys - the two credential types in detail.
• Create, use, rotate, and revoke tokens - step-by-step.
• Token security best practices - storage, least privilege, revocation, and audit.
• Roles and permissions - how to assign the permissions a token inherits.
• Sign up and login - how people sign in to the Console.