# Every error answer in /api/public carries code and type

- Date: 2026-10-25
- Type: Non-breaking change
- Surface: /api/public
- What you need to do: Nothing.
- Address: https://developers.rivr.io/changelog/2026-10-25-api-public-error-bodies

Every error answer under /api/public now has a body with `code`, a stable error code, `type`, the address of the code's page in this portal, and `message`, what went wrong and what to do, in English. Until now only the order endpoints' own errors had a code: a missing or invalid token and a missing scope carried `title`, `status` and `detail` or `error` and `error_description`, an unexpected error and several 404s had no body at all, and the onboarding link endpoints answered with a Swedish message string. The HTTP status of every answer is unchanged, a 204 is still a 204, and the members a body already had stay with the same values, so an integration that reads the status or those members keeps working. Three things look different. The onboarding link endpoints' own errors, the 401 for a token without a platform or a merchant and the next-unread settlement's 401 are the error object instead of a string. The validation problem for a request that can't be read carries `code` request_invalid, and its `type` points to that code's page instead of the RFC. A route that doesn't exist answers with route_not_found. Every code has a page under Error codes, among them token_missing, token_invalid, token_expired, invalid_scope, merchant_mismatch, merchant_token_required, platform_token_required, request_invalid, route_not_found, internal_error, order_id_invalid, device_offline and the onboarding link codes, and every operation in the /api/public reference lists the codes it can answer with. In the sandbox and in production since platform release 2026.10.25.2656.