Quickstart

Quickstart: handle Credicorp API error responses

Every Credicorp API error uses the same envelope: { error: { type, code, message, request_id } }. Branch on the stable code, log the request_id, and show the reader a friendly message — one handler covers 400 through 503 across every endpoint.

2 min read

error{}One shape everywhere
codeBranch on this, not message
request_idLog it for support

The envelope

{
  "error": {
    "type": "validation",
    "code": "invalid_amount",
    "message": "amount must be between 1000 and 150000",
    "request_id": "req_44be1c"
  }
}

type is a broad family (validation, rate_limit, auth, not_found, server). code is a stable machine string. message is human-readable and may change — never branch on it.

One handler for all of them

async function call(url, init) {
  const res = await fetch(url, init);
  const body = await res.json().catch(() => ({}));
  if (!res.ok) {
    const e = body.error || {};
    console.error(`Credicorp ${res.status} ${e.code} (${e.request_id})`);
    throw new ApiError(res.status, e.code, e.message, e.request_id);
  }
  return body;
}

Map status to behaviour

  • 400 validation — fix the request, show the field error.
  • 404 not_found — the id/key does not exist; render a fallback.
  • 409 conflict — usually an idempotency clash; you already have the result.
  • 429 rate_limited — back off and retry (see the rate-limit recipe).
  • 5xx / 503 server/unavailable — retry with back-off, then degrade gracefully.

Frequently asked questions

Should I branch on the message text?

No. The message is for humans and can change wording at any time. Branch only on code, which is a stable contract.

What do I do with request_id?

Log it with every failed call. When you contact support, quoting the request_id lets the team find your exact request in seconds.

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.