Skip to main content
Alforse clients should handle errors in two layers:
  1. Use the HTTP status to decide whether to retry, re-authenticate, fix input, or escalate.
  2. When present, use error.code for product-specific handling and user-facing guidance.

Response shapes

Framework validation and authentication errors usually use the NestJS default shape:
Domain errors can return a stable business code:
message may be a string, an array of validation messages, or a structured object depending on the endpoint and failure type.

HTTP status codes

Authentication and security

These errors usually rely on HTTP status and message rather than a stable error.code.

Plan and quota codes

These codes return 403 Forbidden because the user is authenticated but the tenant is not entitled to complete the action.

File and upload codes

File errors generally return 400 Bad Request; missing file resources return 404 Not Found.

Money and invoice codes

These codes usually return 400 Bad Request.

Contract and workflow codes

These codes usually return 422 Unprocessable Entity, except where noted.

Import limits

Contract import uses 422 Unprocessable Entity for invalid or unsafe spreadsheets:

Retry guidance

  • Safe to retry: idempotent GET requests, 503 reads, and 429 after backoff.
  • Check before retrying: POST, PATCH, and DELETE requests that timed out or returned a transient 5xx; the original write may have succeeded.
  • Do not retry unchanged: 400, 401, 403, 404, 409, and 422.