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.
Developer email
[email protected] — integration questions, bug reports, sandbox issues.
Help centre
Searchable guides and FAQs covering the most common onboarding and webhook questions.
Platform hub
Raise a ticket from inside your account, view past tickets, and manage incident subscriptions.
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.
| Severity | Definition | First response |
|---|---|---|
| SEV-1 | Production down — live decisioning, disbursement or repayment collection failing for all traffic. | ≤ 1 hour, 24/7 |
| SEV-2 | Major feature degraded in live, a workaround exists, or one endpoint is erroring. | ≤ 4 business hours |
| SEV-3 | Sandbox 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.
| Field | Where to find it | |
|---|---|---|
request_id | x-credicorp-request-id header, or meta.request_id in the body. | Required |
environment | Whether the call hit sandbox or live — tell us which key prefix you used (pk_test_ / pk_live_). | Required |
| Endpoint & method | e.g. POST /partner/v1/applications — the full path and HTTP verb. | Required |
| Timestamp | Approximate time of the call in UTC, so we can narrow the log window. | Optional |
| Expected vs actual | One line on what you expected and what you got — HTTP status and the error.code. | Optional |
Idempotency-Key | If 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:
# -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
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:
{
"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.
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 call | OAuth 2.0 & API keys — check the key prefix matches the environment. |
An error.code you don't recognise | Errors reference — every code, what causes it, and how to fix it. |
| Duplicate applications or payments | Idempotency — reuse one key per logical write and retry safely. |
| Webhooks not arriving or failing verification | Webhooks — signature checks, retries and replay. |
429 Too Many Requests | Rate limits — read Retry-After and back off. |
| Unsure how to reproduce safely | Sandbox & 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.
