API key (recommended)
For servers, scripts, and integrations
- Sent in the
X-Api-Keyheader - Long-lived — does not expire hourly
- Created in the dashboard; keys start with
nxs_
Session token (JWT)
For the web dashboard and mobile apps
- Sent as
Authorization: Bearer <token> - Short-lived (1 hour), paired with a refresh token
- Issued by
/api/auth/loginor/api/auth/device
API key authentication (recommended)
For server-to-server access, scripts, and most integrations, use an API key. Unlike a session token, it doesn’t expire every hour.1. Create a key
Sign in to the dashboard, create an API key, and copy it. Keys are shown once and look likenxs_uYc.... Each API key is scoped to one chain and
one network, chosen at creation time (see Key scope below).
2. Send it in the X-Api-Key header
X-Api-Key header. No token
exchange, no refresh loop.
Most endpoints accept a
network query parameter. Supported values:Every value names a chain and a network together, and that pair is exactly the scope of one
API key.
Key scope: one chain, one network
Each API key is bound to a single value from the table above at creation time. That value fixes both the chain and the network, so:- A
CARDANO_MAINNETkey cannot queryCARDANO_PREPRODorCARDANO_PREVIEW. - A
CARDANO_MAINNETkey cannot query Bitcoin or Midnight at all. - To call more than one chain, or more than one network on the same chain, create one key per chain and network under the same account.
network query parameter that does not match the key’s own network returns HTTP 400
Network Mismatch:
network parameter and the request runs against the key’s own network, which is usually
what you want.
What stays uniform across chains is the integration surface, not the credential: one account, one
base URL, one X-Api-Key header, and one docs site. You integrate once and add chains without
re-architecting.
Network scope and capability are separate gates. Market data, wallet analytics, transaction
building, MCP, and IPFS are paid add-ons; their endpoints return HTTP 402
on a key whose plan does not carry the matching add-on, even when the chain and network match.
Blockfrost SDKs and the project ID header
Nexus also serves a Blockfrost-compatible surface athttps://nexus.gerowallet.io/api/v0, and
every Blockfrost SDK sends its credential as a project_id header. On that surface, project_id
is accepted and is exactly equivalent to X-Api-Key: it carries the same nxs_ key, on the same
plan, with the same quota and rate limits.
project_idworks only on/api/v0. Native endpoints under/api/...continue to require theX-Api-Keyheader, and aproject_idheader there is ignored.- If a request sends both, the explicit
X-Api-Keywins.
Nothing changes for native integrations.
project_id exists so that an unmodified Blockfrost
SDK authenticates without code changes. See
Blockfrost compatibility.Session authentication (browser & mobile apps)
The web dashboard and mobile apps authenticate users with short-lived JWT session tokens instead of an API key. You only need this if you’re building a user-facing app that logs people in — for server-to-server API calls, use an API key (above).1. Get an access token
- User Login
- Device Auth
2. Use the Token
Include the access token in theAuthorization header for all API requests:
User Authentication
For web applications and services that require user accounts.Register a New Account
Login
Logout
Invalidates the current session and refresh token:Device Authentication
For mobile applications that don’t require user credentials. Devices are automatically registered on first use.Authenticate Device
Platform Values
Token Management
Token Structure
When you authenticate, you receive:Refresh Tokens
Before your access token expires, use the refresh token to get a new one:- User Refresh
- Device Refresh
Refresh tokens are single-use. Each refresh returns a new refresh token.
Making session-authenticated requests
Once you have a session access token, include it in theAuthorization header. (For
server-to-server access, use an API key in the X-Api-Key
header instead.)
Example: Secure API Client
Here’s a production-ready example with automatic token refresh:Error Handling
Common Authentication Errors
error
Invalid or expired tokenSolution: Refresh your access token or re-authenticate.
error
Wrong email or passwordSolution: Check your credentials and try again.
error
Insufficient permissionsSolution: Check if your account has the required role/permissions.
Best Practices
Secure Token Storage
Secure Token Storage
Web Applications:
- Store tokens in
httpOnlycookies when possible - Use
localStorageonly if cookies aren’t an option - Never store tokens in
sessionStoragefor persistent auth
- Use iOS Keychain or Android Keystore
- Never store tokens in plain text
- Clear tokens on logout and app uninstall
- Store tokens in secure environment variables
- Use secret management services (AWS Secrets Manager, HashiCorp Vault)
- Never log tokens
Token Refresh Strategy
Token Refresh Strategy
- Refresh tokens proactively before expiry (60 seconds buffer)
- Implement retry logic for failed refreshes
- Handle refresh token expiry by re-authenticating
- Queue requests while refreshing to avoid race conditions
Device ID Generation
Device ID Generation
iOS:Android:Web:
Error Recovery
Error Recovery
Handle token errors gracefully:
- 401 with valid refresh token → Refresh and retry
- 401 with expired refresh token → Re-authenticate
- Network error → Retry with exponential backoff
- 403 → Check user permissions, may need different credentials
Next Steps
Quick Start
Make your first authenticated API call
Rate Limits
Understand rate limiting and quotas
Error Handling
Learn how to handle API errors
API Reference
Explore all available endpoints
Security Question? Contact our security team at security@gerowallet.io