GETTING STARTED

Authentication

Every API call is authenticated and scoped to a single organization. Server-to-server traffic uses API keys; the console uses your signed-in session. Data is isolated per organization by row-level security in the database itself.

API keys

An API key is a bearer secret of the form fky_live_…. Send it on every request, either way:

Authorization: Bearer fky_live_x8Qd…
# or
x-api-key: fky_live_x8Qd…

Only a SHA-256 hash of the key is stored — the raw value is shown once at creation and cannot be recovered. Lose it, revoke it, mint a new one.

Scopes

Keys are least-privilege: each carries an explicit set of scopes, and a call returns 403 if the key lacks the one it needs. Grant only what a workload uses.

assess:write

Run assessments (POST /v1/assess)

assess:read

Read assessments, mandates, audit trail

policy:write

Create, activate, backtest policies

policy:read

List and inspect policies

keys:write

Create and revoke API keys

keys:read

List API keys (never the secret)

Console sessions

The dashboard authenticates users with a session JWT (validated by the engine against the identity provider’s public JWKS). Session endpoints — onboarding and account management — accept that token as a Bearer credential. The owner of an organization is granted full scope on session routes.

GET/v1/me
POST/v1/orgs

POST /v1/orgs bootstraps an organization for a brand-new user and is idempotent — a second call returns the same org. From there, mint API keys for your services.

Key lifecycle

POST/v1/api-keys
POST/v1/api-keys/:id/revoke
# create — the raw key is in "key", shown once
curl https://api.fidacy.com/v1/api-keys \
  -H "Authorization: Bearer $SESSION_OR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "checkout-service", "scopes": ["assess:write","assess:read"] }'

Rotate on a schedule and on exposure. Keys are revocable instantly; revocation takes effect on the next request. If a key ever lands in a log, a screenshot, or a chat, revoke it and issue a new one.

Tenant isolation

Row-level security

Every row is tagged with an org_id; the database enforces row-level security so one organization can never read or write another’s data — even under a bug in application code.

Least privilege

The runtime connects as a least-privilege role, not the database owner. The signing key never touches the database.

← PREVIOUS
Hosted MCP NEXT →
Test Mode / Sandbox