Skip to main content
Gero Nexus has two credential types. Pick the one that matches how you’re calling the API:

API key (recommended)

For servers, scripts, and integrations
  • Sent in the X-Api-Key header
  • 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/login or /api/auth/device
These are not interchangeable. An API key (nxs_...) goes in the X-Api-Key header — putting it in Authorization: Bearer returns 401 Unauthorized. Authorization: Bearer is only for JWT session tokens.
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 like nxs_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

That’s the whole protocol for API-key access: HTTPS plus an 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_MAINNET key cannot query CARDANO_PREPROD or CARDANO_PREVIEW.
  • A CARDANO_MAINNET key 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.
Passing a network query parameter that does not match the key’s own network returns HTTP 400 Network Mismatch:
Omit the 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 at https://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.
Two rules:
  • project_id works only on /api/v0. Native endpoints under /api/... continue to require the X-Api-Key header, and a project_id header there is ignored.
  • If a request sends both, the explicit X-Api-Key wins.
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

Response:

2. Use the Token

Include the access token in the Authorization 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:
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 the Authorization 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 token
Solution: Refresh your access token or re-authenticate.
error
Wrong email or password
Solution: Check your credentials and try again.
error
Insufficient permissions
Solution: Check if your account has the required role/permissions.

Best Practices

Web Applications:
  • Store tokens in httpOnly cookies when possible
  • Use localStorage only if cookies aren’t an option
  • Never store tokens in sessionStorage for persistent auth
Mobile Applications:
  • Use iOS Keychain or Android Keystore
  • Never store tokens in plain text
  • Clear tokens on logout and app uninstall
Server Applications:
  • Store tokens in secure environment variables
  • Use secret management services (AWS Secrets Manager, HashiCorp Vault)
  • Never log tokens
  • 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
iOS:
Android:
Web:
Handle token errors gracefully:
  1. 401 with valid refresh token → Refresh and retry
  2. 401 with expired refresh token → Re-authenticate
  3. Network error → Retry with exponential backoff
  4. 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