Authentication

A person signs in through the browser and receives a short-lived DFNS EndUser bearer. A program uses an account-scoped Edel API key. Both use Authorization: Bearer on permitted private REST routes, with different permissions. Public market reads require no credential.

An API key can read its approved account and, with trade scope, place and cancel orders. Deposits, withdrawals, secure identity changes and key management require the owner’s browser session. See account security for the sign-in and setup workflow.

User sessions and owner-approved API keys authenticate access to the same account, with different permissions. Realtime tickets authorize private socket channels.

Owner authority. Deposits, withdrawals, Party changes and key management require the owner’s passkey-backed session.

Delegated access. Read/trade keys can call only the routes allowed for their scope. Private WebSocket access uses a realtime ticket minted through the API, not the raw key.

Position visibility. Positions are private to the account. The account-position endpoint is authenticated and account-scoped, and the public API defines no interface for reading another account's positions.

Signing in establishes a credential and account mapping. It does not by itself complete the account's secure setup or make the account ready to trade. Before automation places an order, read account state and verify that GET /v1/accounts/{accountId}/party reports an active binding. Use the account associated with the approved key; never substitute another account identifier.

The owner completes required passkey ceremonies in the browser. An agent must not collect the owner's session bearer, passkey or DFNS credentials. A scoped key is a delegated machine credential, not the owner's signing identity.

GET /v1/auth/capabilities is public. Read it at startup and again before offering a sign-in method. Offer passkey login only when passkeyLogin is available, and social registration or login only for providers in the corresponding returned list. Existing-user login can be available while new registration is closed.

The current contract does not offer email one-time-code login or lost-passkey credential recovery. Mapping-recovery and registration-attempt recovery routes do not recover a lost passkey. Do not create a replacement identity as an automated recovery step.

Send the API key in the Authorization: Bearer header. API-key requests do not use HMAC signing, signed-byte canonicalization, an authentication timestamp header or a per-request authentication nonce.

Idempotency-Key identifies a logical mutation independently of authentication. When retrying the same order attempt, preserve its body fields, clientOrderId and Idempotency-Key. Owner passkey signatures are used in the separate browser approval flows and cannot be replaced with a trading key.

Read the external-rest-error/v1 envelope, including code, apiKeyRejection, retryable and recoveryActions. An expired, revoked, unknown or malformed key is not repaired by an immediate retry. Stop automated trading when access is refused. Renew through the key's proper issuance path; after revocation, obtain fresh owner direction before reconnecting.

For account channels, mint a realtime ticket with the permitted REST bearer. Send only that ticket on the socket and wait for auth_ok before subscribing. A session bearer or API key must never appear in the socket URL. Follow ticket rotation and reconnect rules.

The API supports current-key inspection, owner key listing and revocation, and the owner-approved device grant. Each operation has its own credential policy: an owner-only route remains unavailable to a trading key.

See API keys and Agent permissions for the supported operations and authorization boundaries.