Platform

Support

Stuck on an integration? Here's how to reach the Credicorp developer team, what to include so we can trace your exact call, and which references to check before you open a ticket. Most issues resolve faster with one good request_id than with a paragraph of description.

Check platform status first. If decisioning, payments or webhook delivery is degraded, an incident is likely already open and you don't need to raise a ticket — subscribe to updates instead.

Support channels

Pick the channel that matches the urgency and tier of your integration. Every channel routes to the same engineering on-call rota; email is the system of record for anything that needs a paper trail.

Partners on the Scale and Platform tiers also receive a dedicated Slack Connect channel and a named integration engineer. To request access, email us from the address registered to your organisation on the hub.

Response targets

These are best-effort targets for a first human response during UK business hours (Mon–Fri, 09:00–18:00 GMT/BST), excluding bank holidays. A severity-1 outage that affects money movement is paged 24/7.

SeverityDefinitionFirst response
SEV-1Production down — live decisioning, disbursement or repayment collection failing for all traffic.≤ 1 hour, 24/7
SEV-2Major feature degraded in live, a workaround exists, or one endpoint is erroring.≤ 4 business hours
SEV-3Sandbox issue, integration question, documentation gap, or feature request.≤ 1 business day

What to include in a ticket

The single most useful thing you can send is the request_id. Every API response — success or error — carries one, both in the JSON body and in the x-credicorp-request-id response header. It lets us pull the exact request, the decisioning trace, and any downstream PISP or identity call from our logs without guesswork.

FieldWhere to find it 
request_idx-credicorp-request-id header, or meta.request_id in the body.Required
environmentWhether the call hit sandbox or live — tell us which key prefix you used (pk_test_ / pk_live_).Required
Endpoint & methode.g. POST /partner/v1/applications — the full path and HTTP verb.Required
TimestampApproximate time of the call in UTC, so we can narrow the log window.Optional
Expected vs actualOne line on what you expected and what you got — HTTP status and the error.code.Optional
Idempotency-KeyIf the call was a write (apply, payment), the key you sent helps us spot retries.Optional

Reading the request_id off a response is one header lookup. Both the SDK and a raw curl call surface it:

bash
# -i prints response headers; grep the request id for your ticket
curl -i https://api.credicorp.co.uk/partner/v1/applications/app_3pQ7r2Kk9 \
  -H "Authorization: Bearer $CREDICORP_SECRET_KEY" \
  | grep -i "x-credicorp-request-id"

# x-credicorp-request-id: req_8Hn2Lp0Wd4Xc
javascript
import { Credicorp } from '@credicorp/sdk';
const credicorp = new Credicorp(process.env.CREDICORP_SECRET_KEY);

try {
  const app = await credicorp.applications.retrieve('app_3pQ7r2Kk9');
} catch (err) {
  // every error carries the request id — quote it in your ticket
  console.error('request_id:', err.requestId);
  console.error('code:', err.code, err.message);
}

A good error body has everything you need to triage and everything we need to trace. This is the standard shape returned across the API:

json
{
  "error": {
    "type": "invalid_request_error",
    "code": "company_not_eligible",
    "message": "Applicant must be a UK incorporated company or LLP.",
    "param": "applicant.company_number",
    "doc_url": "https://dev.credicorp.co.uk/api-reference/errors.html#company_not_eligible"
  },
  "meta": {
    "request_id": "req_8Hn2Lp0Wd4Xc",
    "environment": "live"
  }
}

Redact credentials before you share anything. We never need a secret to help you. Strip these from logs, screenshots and curl commands before sending:

• Secret API keys (sk_live_…, sk_test_…)  • Authorization: Bearer tokens  • Full webhook signing secrets (whsec_…)  • OAuth client secrets  • PISP access tokens.

The request_id is a non-secret reference — it is safe to share and is all we need to find your call. If you ever paste a live secret to us by accident, roll it from the hub immediately; treat it as compromised.

A clean, copy-paste report

Drop this template into your email. Notice the Authorization header is redacted — that's exactly what we want to see.

text
Environment:  live  (key prefix: sk_live_)
Endpoint:     POST /partner/v1/payments
request_id:   req_8Hn2Lp0Wd4Xc
Time (UTC):   2026-06-29T13:42:07Z
Expected:     202 Accepted, payment moves to "processing"
Actual:       409 Conflict, error.code = idempotency_key_reused

curl -X POST https://api.credicorp.co.uk/partner/v1/payments \
  -H "Authorization: Bearer [REDACTED]" \
  -H "Idempotency-Key: pay-2026-06-29-inv-5512" \
  -H "Content-Type: application/json" \
  -d '{ "amount": 250000, "currency": "GBP", "scheme": "pisp" }'

Help yourself first

Most tickets we receive are answered by a page we already publish. Before you write in, a two-minute check here will often unblock you immediately — and if it doesn't, you'll arrive with the right request_id and error code in hand.

If you're seeing…Start here
401 / 403 on every callOAuth 2.0 & API keys — check the key prefix matches the environment.
An error.code you don't recogniseErrors reference — every code, what causes it, and how to fix it.
Duplicate applications or paymentsIdempotency — reuse one key per logical write and retry safely.
Webhooks not arriving or failing verificationWebhooks — signature checks, retries and replay.
429 Too Many RequestsRate limits — read Retry-After and back off.
Unsure how to reproduce safelySandbox & test data — deterministic company numbers and decisions.

Reproduce in sandbox before reporting a live bug. Swap your sk_live_ key for sk_test_ and replay the call against deterministic test data. If it reproduces in sandbox, attach that request_id — no live data, no redaction headaches, and we can trace it the same way.

Reporting a security issue

Suspected vulnerabilities and credential exposure are handled separately from integration support and are triaged immediately. Email [email protected] or follow the disclosure policy at security.txt. Please do not post security reports to the help centre or a shared Slack channel.