Skip to main content
The Gero Nexus API uses standard HTTP status codes and returns a consistent JSON error body to help you diagnose and handle issues gracefully.

Error Response Format

Most errors return this JSON structure. Fields that don’t apply to a given error are omitted (null fields are not serialized), so a typical error has only the first six fields:
Branch on status (or the errorCode when present) for programmatic handling — not on the human-readable message, which may change. There is no code or details field.
Rate-limit (429) and billing (402) responses use a different body. A 429 is { "error": "rate_limit_exceeded", ... }. A 402 has two variants: { "error": "subscription_required", ... } (no active subscription) or { "error": "payment_required", "addon": ... } (a paid add-on isn’t active). See the 402 section below and Rate Limits.

HTTP Status Codes

Success Codes

Client Error Codes (4xx)

The request was malformed or contains invalid parameters. Validation failures include a validationErrors array:
Query-parameter validation messages are prefixed with the controller method (getBlocks.page); request-body validation uses the bare field name (page).Common causes: missing/invalid parameters, invalid JSON body, a value out of range.Solution: check the request parameters against the endpoint’s reference page.
Authentication failed or was not provided.
Common causes:
  • Missing or invalid API key
  • API key sent in the wrong header — an nxs_ key must go in X-Api-Key, not Authorization: Bearer (see Authentication)
  • Invalid or expired JWT session token
Solution: verify your X-Api-Key header (or refresh your session token).
A 402 has two variants — discriminate on the error field (the body is flat, with no errorCode).No active subscription (subscription_required). Nexus has no free tier, so any account without an active subscription gets this on every gated data endpoint. No addon field:
Add-on not active (payment_required). You have a subscription, but the endpoint needs a paid add-on (Market Data, Wallet Analytics, Transaction Builder, IPFS). The addon field names it:
Solution: subscribe or enable the add-on from your dashboard. See Rate Limits.
Authenticated, but not permitted for this action. Some 403s carry a stable errorCode (e.g. EMAIL_NOT_VERIFIED, SUBSCRIPTION_REQUIRED).
Solution: check your plan/permissions, or upgrade.
The 403 SUBSCRIPTION_REQUIRED errorCode comes from account-management actions (creating an API key, activating a subscription). A missing subscription on a data endpoint is instead a 402 with error: "subscription_required" and no errorCode (see above).
The requested resource does not exist.
Common causes: invalid resource ID/hash, a typo in the path, or a transaction not yet confirmed on-chain.
Rate limit exceeded. This response uses the rate-limit body shape (not the standard error envelope) and there are two variants — a per-second throttle and a monthly-quota exhaustion. See Rate Limits for the full contract and how to tell them apart.

Server Error Codes (5xx)

An unexpected error occurred on the server. The message includes the requestId.
Solution: retry. If it persists, contact support with the requestId.
The upstream data providers are unavailable (or the requested network isn’t configured). Some 503s include a providerErrors map:
Solution: retry after a brief delay. Check the status page.
A request to an upstream provider timed out.Solution: retry. For large queries, page through results with a smaller pageSize.

Error Codes

errorCode is optional — it’s present only on specific business/account conditions, not on typical data-endpoint errors (most 400/404/503s omit it). When you do get one, it’s stable and safe to switch on. Examples you may encounter: For everything else, branch on the HTTP status and the error string.

Error Handling Examples

JavaScript/TypeScript

Python

Retry Strategy

Retry transient errors (5xx and the per-second 429) with exponential backoff. Do not loop on a 4xx that won’t change on retry (400, 401, 404), or on a monthly-quota 429 (see Rate Limits).

Best Practices

Branch on status / errorCode

Use the HTTP status (and errorCode when present) for programmatic handling, not the human-readable message.

Log the requestId

Capture requestId from error responses so support can trace the exact failure.

Retry transient errors

For 5xx and per-second 429s, retry with exponential backoff. Don’t retry 4xx that won’t change.

Always check status

Never assume success — check the HTTP status before parsing the body.

Next Steps

Rate Limits

Understand rate limiting and quotas

Pagination

Working with paginated responses

Authentication

Learn about API authentication

API Reference

Explore all available endpoints