API reference overview
The Credicorp partner/v1 API is a JSON-over-HTTPS REST surface for embedding UK business lending: take an application, read an AI-led decision, disburse and collect funds over open banking, and reconcile every movement through signed webhooks.
Everything below applies to every resource — the same authentication, the same envelope for errors, the same cursor pagination and the same idempotency semantics. Read this page once and the individual resource pages become a quick lookup. If you are integrating for the first time, start with the Quickstart, then come back here for the catalogue.
Base URLs
There are two fully isolated environments. The sandbox never touches a real bank, never moves money and never runs a credit search — it is safe to hammer in CI. The live environment is the regulated platform. Tokens, webhook secrets and resource IDs are not interchangeable between the two.
- Live
https://api.credicorp.co.uk/partner/v1- Sandbox
https://sandbox.api.credicorp.co.uk/partner/v1- Auth (OIDC)
https://sso.credicorp.co.uk/oauth2/token- Status
https://status.credicorp.co.uk
A second, customer-facing ring — public/v1 — backs the hosted apply journey and OIDC sign-in. Partner integrations use partner/v1 exclusively; public/v1 is documented under Identity.
All endpoints are versioned in the path. Breaking changes ship as a new major version (/partner/v2); additive changes — new fields, new enum values, new endpoints — are rolled into v1. Build a tolerant reader and you will rarely need to migrate. Track everything in the changelog.
Authentication
Every request carries a bearer access token in the Authorization header. Tokens are short-lived (3,600 seconds) and minted from your OAuth 2.0 client-credentials grant. Each token is bound to a set of scopes — you only get the resources you were granted at onboarding.
# 1. Mint a token from your client credentials curl -s https://sso.credicorp.co.uk/oauth2/token \ -d grant_type=client_credentials \ -d client_id=$CC_CLIENT_ID \ -d client_secret=$CC_CLIENT_SECRET \ -d scope="apply:write decision:read" # 2. Call any resource with the access_token curl -s https://api.credicorp.co.uk/partner/v1/applications \ -H "Authorization: Bearer $TOKEN"
use Credicorp\Client; // SDK exchanges client creds + refreshes the token for you $cc = new Client([ 'client_id' => getenv('CC_CLIENT_ID'), 'client_secret' => getenv('CC_CLIENT_SECRET'), 'environment' => 'live', // or 'sandbox' ]); $apps = $cc->applications->list(['limit' => 20]);
import { Credicorp } from '@credicorp/sdk'; const cc = new Credicorp({ clientId: process.env.CC_CLIENT_ID, clientSecret: process.env.CC_CLIENT_SECRET, environment: 'live', // or 'sandbox' }); const apps = await cc.applications.list({ limit: 20 });
The full token lifecycle, scope catalogue and key rotation are documented under OAuth 2.0. Server-to-server callers that disburse funds must additionally sign the request body — see Request signing.
Resources
The platform is organised around a handful of nouns. An application is decisioned, becomes an account when it funds, and money moves against that account as payment objects. identity verifies the borrowing entity and its officers; webhooks push state changes to you so you never have to poll.
| Resource | Base path | Scope | What it does |
|---|---|---|---|
| Apply | /applications | apply:write | Create, retrieve, list and withdraw business-loan applications. |
| Decisioning | /decisions | decision:read | Real-time AI outcome, indicative APR and reason codes. |
| Payments | /payments | payments:write | Payment links, collection schedules and repayments via PISP. |
| Identity | /identity | identity:read | KYB on the company, KYC and AML checks on its officers. |
| Accounts | /accounts | accounts:read | Funded loan accounts, balances and servicing state. |
| Webhooks | /webhooks | webhooks:manage | Register endpoints and subscribe to signed events. |
Conventions
Requests & responses
Send and receive application/json; UTF-8 throughout. All monetary amounts are integer pence in GBP — 2500000 is £25,000.00. There are no floats anywhere in the API. Timestamps are RFC 3339 / ISO 8601 in UTC (2026-06-29T14:05:00Z). Every object carries a stable, prefixed id (app_, dec_, acc_, pay_) and a string object field so you can route polymorphically.
Errors
Conventional HTTP status codes signal the outcome. 2xx is success, 4xx is a problem with your request (a bad parameter, a failed validation, a missing scope) and 5xx is a problem on our side. Every error returns the same machine-readable envelope, with a type you can branch on and a request_id to quote to support.
{
"error": {
"type": "validation_error",
"code": "amount_below_minimum",
"message": "amount_pence must be at least 100000.",
"param": "amount_pence",
"request_id": "req_7f3aK9d2"
}
}| Status | Type | Meaning |
|---|---|---|
| 200 201 | — | Success. 201 on resource creation. |
| 400 | validation_error | Malformed body or a parameter failed validation. |
| 401 | authentication_error | Missing, expired or invalid access token. |
| 403 | permission_error | Token lacks the required scope. |
| 404 | not_found | No such resource, or not visible to this client. |
| 409 | conflict | Idempotency-Key reused with a different body, or illegal state transition. |
| 429 | rate_limited | Too many requests — back off and retry. |
| 500 503 | api_error | Something failed our side. Safe to retry idempotent calls. |
The full code list lives on the Errors page.
Idempotency
Every POST accepts an Idempotency-Key header — any unique string (a UUID is ideal). We persist the first response against that key for 24 hours, so a retried request returns the original result instead of creating a duplicate application or taking a payment twice. Always set it on writes that move money or create records. Reusing a key with a different payload returns 409 conflict. See the idempotency guide.
Pagination
List endpoints are cursor-paginated. Pass limit (1–100, default 25) and walk forward with starting_after={id}. The envelope reports whether more pages exist; never infer the end from a short page.
{
"object": "list",
"data": [ { "id": "app_8Kd2c9Qm", … } ],
"has_more": true,
"next_cursor": "app_8Kd2c9Qm"
}Details and ordering guarantees are on the Pagination page.
Rate limits
Limits are applied per client, per environment, on a sliding window. Each response carries your budget so you can throttle pre-emptively rather than waiting for a 429.
| Header | Meaning |
|---|---|
RateLimit-Limit | Requests permitted in the current window. |
RateLimit-Remaining | Requests left in this window. |
RateLimit-Reset | Seconds until the window resets. |
Retry-After | On a 429, seconds to wait before retrying. |
Default ceilings and how to request an uplift are on the Rate limits page.
An OpenAPI 3.1 document for the whole partner/v1 surface is published at https://api.credicorp.co.uk/partner/v1/openapi.json. Point your generator at it to scaffold a typed client, or import it into Postman / Insomnia. Our official SDKs are generated from the same spec.
