Skip to main content

Response Envelope

All API responses are wrapped in a standardized envelope for consistent error handling and observability. This allows clients to handle responses uniformly across all endpoints.

Envelope Structure

enum
required
Operation result: success or failure
enum
Machine-readable error code when status is failure. One of:
  • VALIDATION_ERROR - Invalid request parameters
  • POLICY_VIOLATION - Policy denied the operation
  • PIPELINE_ERROR - Internal processing failure
  • CONFIRMATION_FAILED - Transaction confirmation failed
  • null - No error (success)
enum
Pipeline stage where failure occurred:
  • validation - Request validation
  • policy - Policy evaluation
  • build - Transaction building
  • sign - Signing operation
  • send - Network submission
  • confirm - Confirmation timeout/failure
  • gateway - Gateway-level error
  • null - No failure
enum
required
Current or final pipeline stage:
  • validation
  • policy
  • build
  • sign
  • send
  • confirm
  • completed
  • gateway
string
required
Unique request identifier (UUID) for debugging and audit correlation
object
The actual response payload (present on success)
string
Human-readable error message (present on failure)
string
Alternative error message field (some endpoints)

Success Response Example

Error Response Example

Transaction-Specific Behavior

Transaction endpoints may return HTTP 200 with status: "failure" when the transaction itself fails after being created.
Example - Transaction failed during confirmation: Request:
Response (HTTP 200):
Always check the envelope status field, not just the HTTP status code, to determine operation success.

Client Handling

TypeScript Example

Python Example

Error Code Reference

When: Invalid request parameters, missing required fields, malformed dataHTTP Status: 400 Bad Request (usually)Example Scenarios:
  • Invalid UUID format
  • Missing required fields
  • Out of range values
  • Schema validation failures
  • Invalid API key
  • Missing authentication headers
Retry: No - fix the request parameters

Stage Progression

Transaction processing follows these stages: The stage field reflects the current or final stage in this progression.

Trace ID Usage

The traceId field is essential for debugging:
  1. Log Correlation - Search logs for specific request traces
  2. Support Tickets - Include trace ID when reporting issues
  3. Audit Trails - Link audit events to originating requests
  4. Distributed Tracing - Track requests across services

Best Practices

Always parse the response envelope before accessing data
Check status === 'success' before proceeding with business logic
Log traceId for all errors to facilitate debugging
Handle errorCode types differently based on retry eligibility
For transactions, poll the status endpoint until stage reaches confirmed or failed