LENDING / RELIABILITY

Errors and retries

AC's relay returns controlled JSON error bodies for many gateway validation and execution failures. Downstream business outcomes are generally returned as XML.

Example controlled error

{
  "error": "invalid_request",
  "request_id": "EXAMPLE_REQUEST_ID"
}

The X-AC-Request-ID response header can help AC investigate a problem. Do not send API keys or customer application bodies in support tickets.

Common HTTP responses

HTTP status	Typical cause	Action
`200`	Request processed at HTTP level	Inspect XML `<result>` and offers
`400`	Invalid or unsafe XML, malformed query/token	Fix your request; do not retry unchanged
`401` / `403`	Authentication failure, disabled client or token binding	Verify credentials and access
`404`	Route not found	Verify the method/path issued by AC
`429`	Throttled by gateway or rate limits	Back off; respect `Retry-After` if present
`502`	Downstream failure, unsafe response or connectivity problem	Stop blind retries and investigate
`503`	Gateway service unavailable or misconfigured	Escalate through AC support

These are common classes of response, not a promise that every integration layer returns an identical payload for each status.

Retry rules

Never automatically resubmit a consumer application when the result of the first attempt is uncertain. A timeout may mean the application was already accepted upstream.
Avoid simultaneous duplicate submissions for the same applicant and application reference.
For read-only results polling, retry conservatively within the valid token lifetime, with rate-limit-aware backoff.
For failures involving an unknown submission outcome, provide the request ID and application reference to AC for investigation.

404 troubleshooting

When a new route is added to API Gateway, its Lambda integration may still reject the route. An error=not_found response with an AC request ID can be generated by the relay if the path is not in its routing allowlist. This was corrected for POST /post during the October 2026 rollout.