Authentication
How to authenticate with the OBSDN API using signers and API keys
Use this guide to register a signer, manage API keys, and authenticate your API requests.
Overview
OBSDN auth has three pieces, each with a different job:
- Sender wallet — owns your funds. You sign with it for actions that move funds (withdraw, transfer) or register an order signer. Verified on-chain by the
Obsdncontract. - Signer wallet — a separate wallet authorized to place orders for the sender. Verified on-chain by the
Obsdncontract at settlement. - API key pair —
api_key+api_secret. Used to sign every API request so the backend knows the caller is you. Verified off-chain by the OBSDN backend; has no on-chain effect.
You register a signer once via POST /auth/signers; that call returns your first API key. Additional keys come from POST /auth/api-keys.
Register a Signer
Both the sender wallet and the signer wallet sign EIP-712 typed data, then a single call posts both signatures together. The response includes the first API key pair.
See the Register Signer reference for the request schema, Getting Started for an end-to-end curl example, and the Signing Guide for the EIP-712 payloads.
The response (under data) returns the first API key pair:
{
"api_key": {
"api_key": "obsdn_abc123...",
"api_secret": "secret_xyz789...",
"nm": "My Trading Bot",
"sndr": "0x1234...",
"signer": "0xabcd...",
"crt_ts": "1734000000000000000",
"exp_ts": "1735000000000000000",
"is_ro": false
}
}exp_ts is "0" for keys with no expiration; otherwise a Unix nanoseconds timestamp.
api_secret immediately — it is shown only once and cannot be retrieved later.Authenticating REST Requests
Every protected REST endpoint requires three headers:
| Header | Value |
|---|---|
x-api-key | API key identifier (api_key) |
x-api-timestamp | Current Unix time in seconds (string) |
x-api-signature | base64(HMAC-SHA256(api_secret, timestamp + method + path + body)) |
The HMAC prehash concatenates the timestamp, the uppercase HTTP method, the URL path (no scheme, host, or query string), and the raw request body. Use the API secret as the HMAC key — the secret itself is never sent over the wire.
Requests are rejected with 401 if the timestamp is more than 5 seconds off the server clock, so regenerate the signature for every call.
Example
TS=$(date +%s)
METHOD=GET
URL_PATH=/portfolio
BODY=""
SIG=$(printf '%s%s%s%s' "$TS" "$METHOD" "$URL_PATH" "$BODY" \
| openssl dgst -sha256 -hmac "$API_SECRET" -binary \
| base64)
curl "https://api.obsdn.trade$URL_PATH" \
-H "x-api-key: $API_KEY" \
-H "x-api-timestamp: $TS" \
-H "x-api-signature: $SIG"For requests with a JSON body, pre-serialize the body once and reuse the same string in both the prehash and the request — whitespace or key-order differences between the signed and sent bytes will invalidate the signature.
Treat api_secret like a private key. It is the HMAC key, never transmitted; rotate it on suspected exposure by
deleting the key with DELETE /auth/api-keys and creating a new one.
Authenticating WebSocket
Private WebSocket channels (order, position, portfolio) require an auth message before subscription. The signature uses the same api_key / api_secret, but the prehash is ${api_key},${timestamp} and the timestamp window is ±60 seconds.
See WebSocket Overview for the full recipe.
API Key Lifecycle
All three endpoints below require the HMAC headers from Authenticating REST Requests.
Create
POST /auth/api-keys{
"nm": "Read-Only Dashboard",
"is_ro": true
}Both fields are optional; is_ro defaults to false. The response shape matches POST /auth/signers — { "api_key": { ... } } with a fresh api_key and api_secret. Save the secret immediately; it is shown only once. See the Create API Key reference.
Read-Only Keys
Set is_ro: true to issue keys that can read data but cannot:
- Place or cancel orders
- Modify positions or leverage
- Transfer or withdraw funds
Use read-only keys for dashboards, analytics, and monitoring jobs.
List
GET /auth/api-keysReturns all API keys for the authenticated account. The api_secret field is empty on every entry — secrets are only returned at creation time. See the List API Keys reference.
Delete
DELETE /auth/api-keys{
"api_keys": ["obsdn_abc123", "obsdn_def456"]
}Deletion is immediate and irrevocable — the keys can no longer authenticate any request. See the Delete API Keys reference.
Security Notes
- Use separate signer wallets. If the signer key leaks, only signing authority is exposed — funds remain controlled by the sender wallet, which can revoke the signer.
- Create read-only keys for monitoring. Limit exposure for dashboards and analytics jobs.
- Rotate keys. Delete stale keys with
DELETE /auth/api-keysand create new ones. - Store secrets securely. Use environment variables or a secret manager — never commit secrets, never log them.
Error Codes
| Code | Message | Solution |
|---|---|---|
| 401 | authentication required | Missing/invalid x-api-key, x-api-signature, or x-api-timestamp; or timestamp is more than 5s off the server clock |
| 403 | read-only key | Use a non-read-only API key for this operation |
| 403 | invalid signature | For orders/withdrawals, verify the EIP-712 payload (see Signing); for the request HMAC, verify the base64 digest and the prehash format (timestamp + METHOD + path + body) |