Skip to content

Errors & Exceptions

Nubra REST API V3 returns compact error payloads and a small set of important status codes.

This page documents the response shape that clients should handle in the current V3 flow.

Error Response Format

The current REST V3 error shape is:

{
  "error": "Description of the issue",
  "nubra_error_code": ""
}

Fields

Field Type Description
error string Human-readable explanation of the failure.
nubra_error_code string Reserved for future use. Currently empty ("").

HTTP Status Codes

400 - Bad Request

The request is invalid or violates trading rules.

Typical causes include:

  • missing required fields
  • invalid or unsupported parameters
  • wrong data types
  • invalid instrument identifiers
  • quantity or price rule violations
  • malformed trigger, stop-loss, target, or basket payloads

Example:

{
  "error": "Enter valid inputs to proceed.",
  "nubra_error_code": ""
}

440 - Authentication / Session Failure

Some authenticated endpoints may return HTTP 440 when the session is expired, invalid, or no longer usable.

Clients should treat this as a re-authentication case rather than a retriable trading error.

500 - Internal Server Error

An unexpected backend or OMS failure occurred.

Typical causes include:

  • upstream OMS or internal service failure
  • internal validation or routing failure
  • unexpected backend exception

These errors are not caused by normal client input and should be logged and retried carefully.

For HTTP 400

  • validate request payloads before sending
  • confirm enum values and field names
  • confirm instrument IDs and price rules
  • surface the error string directly in logs or client diagnostics

For HTTP 440

  • refresh or recreate the session
  • repeat the request only after authentication succeeds again

For HTTP 500

  • retry after a short delay
  • use exponential backoff for automated systems
  • log request context and response body for debugging
NEO Assistant