2 min read
What it means
The request could not be parsed or was structurally wrong.
Common causes
Malformed JSON, a wrong or missing Content-Type, or a body that is not the shape the endpoint expects.
Example response
{
"error": {
"type": "invalid_request_error",
"code": "invalid_request",
"message": "The request could not be parsed or was structurally wrong."
}
}
How to handle
Fix the request before resending — the same bytes will always fail.
See the error code catalogue for the specific code that accompanied this status.
Where it sits in the error model
A 400 is one of the invalid_request_error class of responses. On the Credicorp API the HTTP status is only the broad classification; the exact reason travels in error.code, and — for field-level problems — the offending input is named in error.param. Build your handling around the code, not the wording of error.message, which may be refined over time.
This class is deterministic: retrying the identical request reproduces the identical error, so a resilient client separates it from the transient 429 and 5xx classes it does retry. Surface a clear, actionable message to the caller and, where error.param is present, point them at the exact field to correct.
Frequently asked questions
Should I retry a 400?
No. The request will fail identically until you fix the underlying problem. Retrying wastes your rate-limit budget.
Where is the specific reason?
In error.code and, for field errors, error.param. The HTTP status is the class; the code is the specifics.
Is the response body always JSON?
Yes — API errors are always the JSON error envelope. HTML back means you hit an edge/proxy layer, not the API.
Funding for UK limited companies
Credicorp lends to your company, not to you personally — short-term working capital with no personal guarantee. See what your business could access.