Skip to main content
Buildmarkets uses standard HTTP status codes along with structured JSON error bodies to communicate what went wrong. This page is your reference for understanding and handling error responses.

Error response format

All error responses return a JSON body with a consistent structure:

HTTP status codes

2xx — Success

4xx — Client errors

5xx — Server errors

Common error codes

Authentication & authorization

Validation errors

Account errors

Trading errors

Funding errors

Rate limits

Buildmarkets enforces rate limits to ensure platform stability for all partners. When you exceed a rate limit, you receive a 429 Too Many Requests response with a Retry-After header indicating how many seconds to wait before retrying:
Implement exponential backoff in your retry logic. Do not immediately hammer the API after receiving a 429.

Handling errors in practice

Always check the error code, not just the status

Use the code field in the error body for programmatic error handling.

Log request IDs

Always log the request_id from error responses. When contacting Buildmarkets support, provide this ID so the support team can trace the request through internal systems.

Retry strategy

  • 400, 401, 403, 404, 409, 422 — Do not retry. These are deterministic errors that will not resolve with a retry.
  • 429 — Retry after the Retry-After delay.
  • 500, 503 — Retry with exponential backoff (e.g., 1s, 2s, 4s, 8s). After 3–5 retries, alert your operations team.