The Kash REST API returns errors as RFC 7807 Problem Details JSON. Every response carries a stableDocumentation Index
Fetch the complete documentation index at: https://docs.kash.bot/llms.txt
Use this file to discover all available pages before exploring further.
code and a type URL that
resolves to the error’s documentation page on this site:
code field is the stable identifier — branch on it from
your client. The type URL is for humans (and AI agents) following
the link. The detail string is a human-readable explanation that
may evolve over time; don’t parse it.
How to read this catalogue
Each per-code page is the canonical reference for what triggers the error, why it happens, and how to recover. Pages are short by design — when something fires, you should be able to read the relevant page in under a minute and know your next move. The catalogue is single-sourced from the public-API service’s markdown atapps/public-api/docs/api-errors/<CODE>.md in the Kash
monorepo. Mintlify pages here are auto-generated from those source
files at every release; the contract test
tests/unit/errors/documentation-url.test.ts enforces that every
runtime ErrorCode has a corresponding source-of-truth page.
Stability promise
Thecode field is part of the public-API contract. We follow these
rules:
- Adding a new
codeis non-breaking — your client should fall through to a generic error handler for any code it doesn’t recognize. - Renaming a
codeis breaking and requires a version bump. - Repurposing a
code(changing what conditions cause it to fire) is breaking and requires a version bump. - Changing the HTTP status for an existing
codeis breaking.
title field is also stable — it appears in customer-facing
logs and dashboards. The detail string is not stable; it may
be reworded for clarity in any release. The requestId and
instance fields are present on every error response and are the
fastest path to support — quote them when filing an issue.