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.

ScopeGrants
assess:writeRun assessments (POST /v1/assess)
assess:readRead assessments, mandates, audit trail
policy:writeCreate, activate, backtest policies
policy:readList and inspect policies
keys:writeCreate and revoke API keys
keys:readList 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

  • ·Every row is tagged with an org_id; the database enforces row-level securityso one organization can never read or write another's data, even under a bug in application code.
  • ·The runtime connects as a least-privilege role, not the database owner. The signing key never touches the database.