API Access

Build programmatically on your data models with the REST APIs — the same governed models that power workspaces, agents, and data apps, with the same access rules enforced on every request. Sign in as yourself with a Bearer token, or — for anything running server-to-server, like custom applications, scripts, and integrations — use an API key scoped to a group. The key acts with the group's permissions, so you can adjust what it can access at any time without regenerating it.

The REST APIs

Credible splits its REST surface three ways, matching the architecture: the Admin API manages organizations and their resources, the Data API runs queries, and the Retrieval API searches your models. Admin traffic and query traffic run on separate planes, so a busy admin job never slows a query. All three enter through the same gateway, where access rules are checked and every request is logged.

Authentication

Every request to the REST APIs carries an Authorization header, and Credible accepts two schemes:

Bearer Tokens (User Auth)

Credible's APIs are a standard OAuth resource server: they accept access tokens issued by Credible's identity provider (Auth0) through your organization's SSO. When you sign in — in the browser or via the CLI's device flow — you get a short-lived access token, and every request made with it acts with your permissions, enforced by the same access rules as every other surface.

The easiest way to get a token is the CLI:

cred login <your-org>

After login, the CLI stores your tokens in ~/.cred and uses them for every command. For quick API testing, you can pass the same access token directly:

curl -H "Authorization: Bearer <access-token>" \
  https://<your-org>.data.credibledata.com/api/v0/environments

Bearer tokens expire and are refreshed through the OAuth flow, so they're the right fit for interactive use — for anything long-running or unattended, use an API key instead.

Create an API Key

1. Create a Group

Navigate to <your-org>.app.credibledata.com:

1. Click Users & Groups in the bottom left of the sidebar
2. Switch to the Groups tab
3. Click + Create Group and name your group (e.g., ai_agents_group)

2. Grant Environment Access

Navigate to the environment you want this group to access:

1. Click Permissions on the environment page
2. Add your group and select the appropriate role
3. Verify the group appears in the permissions list

3. Generate the Key (CLI)

Install the Credible CLI, authenticate, and generate an API key for your group:

# Install the CLI globally
npm i -g @credibledata/cred-cli

# Login to your organization
cred login <your-org>

# Create a group access token
cred add group-access-token <group-name> <token-name>

The final command outputs the API key. Store it securely in your application's credential storage or environment variables — all requests made with it act with the permissions of the group.

Using the Key

Pass the key in the Authorization header on every request:

Authorization: ApiKey your-api-key

This works across Credible's programmatic surfaces: the REST APIs above, and the MCP server for custom agents.

Tenant Isolation for Embedded Products

When your product queries Credible on behalf of your customers, tenant isolation is declared in the model and enforced at the gateway — not reimplemented in application code. The pieces are the ones above:

1. Declare the given in the model. A secure given such as #(secure) ALLOWED_TENANTS :: string[], with a where: or #(authorize) that reads it, scopes every query on the source tenant by tenant.
2. Give each tenant a group and a key. An API key acts as its group, so create one group per tenant (or per plan tier) and generate its key. Requests made with the key resolve secure givens from the group — the caller's verified identity, for a server-to-server caller.
3. Grant the tenant's values. On the Access Control page, grant the group the tenant IDs it may see.

From then on every query that arrives with that key — through the Data API, the Retrieval API, or MCP — is scoped to that tenant before it runs, and logged with the group that made it. Your application never handles a tenant filter, and a bug in the app cannot widen what a customer sees. For interactive analytics inside your product, ship a data app: it queries through the same gateway, so a customer who opens it sees only their rows.

Have an authentication requirement this doesn't cover? Email us.