Authentication

Base URL

Every endpoint lives under a single base URL:

https://api.resetdata.ai/api/v1

So chat completions is POST https://api.resetdata.ai/api/v1/chat/completions, and model detail is GET https://api.resetdata.ai/api/v1/models/detail?slug=<model-slug>.

Two easy mistakes

• The path segment is /api/v1 — the api appears in both the hostname and the path. It is not https://api.resetdata.ai/v1.
• Model detail is /models/detail, singular. /models/details returns 404.

The internal addresses that actually run the models are not reachable from outside our network, and know nothing about your keys, pricing or the catalog. Always go through api.resetdata.ai.

API keys

Requests authenticate with a bearer API key scoped to a single workspace.

Authorization: Bearer $RESETDATA_API_KEY

Keys begin with sk-rd-. Anything presented with that prefix is treated as an API key; other bearer tokens are treated as app session tokens.

Check the variable is actually set

An unset or empty $RESETDATA_API_KEY sends a malformed header and returns 401 Invalid authorization header format — which is easy to misread as a problem with the endpoint. Confirm with:

echo "${RESETDATA_API_KEY:0:6}"   # should print sk-rd-

Note that VAR=value curl ... does not work here: your shell expands $RESETDATA_API_KEY before applying the assignment, so it substitutes the old value. Use export as a separate statement.

Creating a key

Keys are managed from API keys in the ResetData app. Creating one requires the api_keys:manage permission — owners, admins and members have it; viewers do not.

When you create a key you can set:

Option	Notes
Name	Required, and unique within the workspace.
Expiry	Optional. Leave empty for a key that never expires.
IP allowlist	Optional. Individual IPs or CIDR ranges; enforced on every request.

The key is shown once

The full key is displayed only at creation time and is never retrievable afterwards — we store a hash, plus the first few characters for identification. Copy it into your secret store immediately. If you lose it, create a new key.

Scope and billing

• Each key is scoped to one workspace. Usage and spend are billed to that workspace’s wallet.
• A key may optionally be narrowed to a single project.
• API keys work only on the inference endpoints (/chat/completions, /embeddings, /rerank, /images/generations, /audio/* and the model listing). Account, billing and workspace management endpoints require an app session, not an API key.

Rotation and revocation

There is no in-place rotation. To roll a key, create the replacement, deploy it, then delete the old one — in that order, so you are never without a valid key.

Deleting a key takes effect within about a minute, as validation results are cached briefly. Note also that removing a member from a workspace immediately deactivates every API key that member created — worth knowing before offboarding someone whose key is running in production.

Last used on the key list can lag by up to around 30 seconds, so treat a fresh “Never” on a just-deployed key as inconclusive.

Handling keys safely

• Set keys through environment variables or a secret manager; never commit them.
• Use the IP allowlist for server-side workloads with stable egress addresses.
• Set an expiry on keys issued for trials, contractors or one-off migrations.
• Prefer one key per application, so revoking one doesn’t take down everything.

Caution

If a key is leaked, delete it immediately from API keys and issue a new one.