Skip to main content
Every error from api.kash.bot is an RFC 7807 Problem Details body with Content-Type: application/problem+json.

Wire shape

Some codes add extension members at the top level of the body, for example supported on API_VERSION_UNSUPPORTED. Each code’s catalogue page lists them. Retryable errors carry Retry-After in seconds.

How to handle errors

Branch on code, not on status or the message. A 409 can mean a dozen different things; code is unambiguous.
The SDK also throws typed subclasses (KashRateLimitError, KashAuthorizationError and so on); see the catalogue overview for the mapping.

Status code conventions

The error catalogue

Every code has its own page at https://docs.kash.bot/developer-docs/api-errors/<CODE>, which is exactly the type URL in the response. The error catalogue lists all of them by status. The kash CLI carries an offline copy:

What errors never contain

  • No stack traces and no raw database or chain-node error strings. Details are sanitised.
  • No hints about other users’ data. Reading someone else’s trade returns 404 RESOURCE_NOT_FOUND.
  • No dependency names. An outage surfaces as a generic DEPENDENCY_UNAVAILABLE; your requestId lets ZeroID find the cause.

Reporting problems

Report it from the info button in the Kash web app → Feedback → Report a bug, with the requestId. One id is enough for ZeroID to find the request and everything it triggered.

Next

Idempotency

Retry writes safely without duplicates.

Pagination

Walk list endpoints with cursors.