Errors, retry and recovery
Distinguish input, access, conflict and provider failures before deciding whether to retry.
Recover when outcomes are unknown
Retain the application case, service references and document version. Duplicate callbacks do not create transactions; out-of-order events require reconciliation. Signing and validation outcomes are assessed separately.
Practice the offline reconciliation journalDo not recreate an uncertain request
A lost response does not prove that a request was not processed. Keep caller references, x-billcode-id and context-specific tokens; query under the contract or reconcile with the operator before resubmitting create/sign actions.
An uncertain outcome is not a new request
Persist local and service references before advancing. When responses are lost, reconcile using correlation identifiers and the contract; event delivery retries are distinct from another signature. No retry schedule or timeout is assumed.
Recovery decisions by error
Reference model, not a production API contract. Examples use synthetic data only.
If the table is wider than its frame, scroll horizontally to see all columns; use arrow keys when the table region has focus.
| HTTP | Code | Action |
|---|---|---|
| 400 | INVALID_REQUEST | Correct the payload before retry. |
| 401 | AUTHENTICATION_REQUIRED | Review approved access; avoid repeated unauthorized calls. |
| 404 | NOT_FOUND | Check ID and environment; do not create an automatic replacement. |
| 409 | IDEMPOTENCY_CONFLICT | Compare against the stored transaction and reconcile. |
| 422 | VALIDATION_ERROR | Correct the invalid field and retain the source record. |
| 503 | PROVIDER_TEMPORARY_FAILURE | Reconcile uncertainty; retry only under approved policy. |
When no HTTP response arrives
Connection loss or timeout does not prove that creation never happened. Preserve the source record, avoid automatic replacement and reconcile using deployment procedures. Escalate unresolved outcomes to operations.