Skip to main content

Safe retry rules

  • Any route: if the response is code = 44 (CASHBOX_BUSY), back off briefly and resend the same request unchanged — this is expected when another operation is in flight or a previous document is still pending, not a fatal error.
  • /sale, /refund:
    • Never generate a new documentExtID during retry of the same business operation.
    • Preferred recovery from unknown delivery: resend same request with same documentExtID.
    • If still in progress (docStatus=0), poll /check_status.
  • /deposit, /withdraw:
    • If timeout happens after send, use /check_status first before attempting another cash operation.
    • If /check_status returns code = 9 after unknown delivery, resend same request with same documentExtID.
    • Note: for some execution failures before finalization, the server may roll back and delete the open cash document; in that case code = 9 is expected and resend is the correct recovery action.
    • Note: for print failures (code = 15), document is typically kept for print recovery, so /check_status and /check_copy should be used.
  • /close_shift:
    • If failed with code = 24 (unclosed checks exist), use explicit openOrdersOperation (delete or renew) per business policy and resend.
    • If delete/renew itself fails (no code, see §12.3), do not blindly retry the same openOrdersOperation — read message to determine the reason (settings forbid the action, or a specific check needs manual handling) before deciding on the next step.