API error recovery by code

Code	Meaning	Retry strategy
1	Signature/auth error	Do not retry same request. Rebuild sign, verify merchantId, resend once.
6	Shift is not open	Do not resend the same operation; open a shift (or verify shift state) first.
9	Document not found	In unknown-delivery recovery: resend same operation with same documentExtID; in normal flow: verify ids and payload.
15	Document not printed	Business operation may be completed; run print-error recovery flow below.
24	/close_shift rejected: unclosed checks exist	Resend /close_shift with explicit openOrdersOperation (delete or renew) per business policy.
44	Cashbox busy — another operation is running, or a document from a previous operation is still pending	Transient. Wait a short backoff (1-2 s) and resend the exact same request. Do not change documentExtID. If the same code repeats for longer than your policy allows, stop auto-retrying and surface to an operator — the blocking document may need manual resolution on the device.
-1	Unexpected/uncaught server-side error	Treat as a generic failure; route-specific retry policy (see §12.4) or surface to an operator.
(absent) / null	Known business-rule error (e.g. cashbox settings forbid the requested action, a specific check blocks an operation)	Not an unexpected failure — do not treat as a generic/unknown error. Show message to the user as-is; it may name the specific document (e.g. by receipt number) that needs to be resolved before retrying.

[!NOTE] Note code values 2, 3, 4, 5, 7, 8, 10, 11, 12, 13, 14, 23 do not exist in the current server implementation — any unrecognized code the server might have historically been asked to emit is normalized to -1 before being sent. Do not build client-side branching on those specific values; if you have legacy code doing so, treat it the same as -1.