Error codes

Every non-2xx response from the LOAN4BANK API includes both a standard HTTP status code and a stable `L4B-XXX` code inside the response body. The HTTP status tells you the class of problem (400 for validation, 401 for authentication, 402 for plan gate, 403 for permission, 404 for missing resource, 409 for a conflict, 422 for a semantically valid but rejected payload, 429 for rate limiting and 5xx for platform issues). The `L4B-XXX` code is what your integration should branch on, because a single HTTP status often maps to many different root causes — for example, three different `L4B` codes can each return 400 with a different remediation.

For production-grade robustness, always retry idempotent requests on 429 and 5xx responses using exponential backoff with jitter, honouring the `Retry-After` header when present. Never retry a 4xx response other than 408 and 429 — you'll only trip circuit breakers on your side. Log the request id from the `X-Request-Id` response header on every failure; our support team can pull the full server-side trace with just that id, so tickets close in minutes instead of hours.

Webhooks add a second failure surface. Any 4xx or 5xx you return from your endpoint puts the delivery into our retry queue (5 attempts over 24 hours with exponential backoff). If your handler is temporarily degraded, return 503 explicitly so we back off aggressively; if the payload is genuinely bad, return 422 so we mark the delivery as permanently failed and surface the reason on your dashboard. Always verify the `X-L4B-Signature` header before parsing the body — a signature mismatch is code `L4B-WBHK-401` and should never be treated as a transient problem.