
AI crawlers and GEO on the developer portal
The developer portal is built to be read by machines, not just people. It welcomes AI crawlers via robots.txt, llms.txt and…
Read →
Authentication on the public ring (there is none)
The public ring has no authentication — and that is the correct design. There is nothing to authenticate: every endpoint either…
Read →
Caching public-API responses
Most public-API reads are safe to cache, and caching them is the single biggest performance win. The loyalty ladder, CMS pages,…
Read →
Choosing an SDK or raw HTTP
Use an SDK when you want auth, retries, pagination and typing handled for you. Use raw HTTP for a language with no SDK, a thin…
Read →
Choosing between webhooks and polling
Reach for webhooks when you need to react to events promptly, and poll only when you cannot host an endpoint. Webhooks push each…
Read →
Choosing the right endpoint
Not sure which public endpoint you need? Start here. This guide maps common goals to the right endpoint — reading products,…
Read →
Common integration patterns
Most integrations fall into five shapes: a quote widget, an embedded application, a comparison listing, an AI assistant and a…
Read →
Data and privacy on the public ring
The public ring returns published figures only — no customer data, ever. The two write endpoints record real rows (a lead, a…
Read →
Data you can read vs submit
The public ring is easy to reason about once you split it into reads, submits and off-limits. You can read public vocabulary —…
Read →
Design principles of the public API
The public API follows five principles you can rely on. It is keyless by default, keeps all per-customer PII private, returns…
Read →
Designing a reliable webhook consumer
A reliable webhook consumer does four things: verify, acknowledge fast, dedupe, and reconcile. Verify the signature over the raw…
Read →
Environments and the sandbox
Partner integrations get an independent sandbox project with its own OAuth client and its own rate-limit bucket. The public ring…
Read →
Errors and status codes on the public API
Every public-API response uses standard HTTP status codes and a consistent error envelope. A read returns 200, a successful…
Read →
Errors, status codes and safe retries
Errors come back as JSON with a stable machine code and a human message. 4xx means fix the request; 429/5xx are retryable with…
Read →
Feature flags and endpoint availability
Some public endpoints are gated behind feature flags and may return a clean "unavailable" response instead of data. The Slice…
Read →
Idempotency and safe retries
Send an Idempotency-Key on every mutating partner call. The server records the first result against the key and replays it for…
Read →
Money-out: the one manual gate
Everything in the platform is automated except money-out, which is a single governed manual gate. Decisioning is authoritative;…
Read →
OAuth 2.0 client credentials for partner/v1
Partner API calls authenticate with the OAuth 2.0 client-credentials grant. You exchange a client ID and secret for a short-lived…
Read →
Privacy and PII on the public ring
No per-customer personal data ever crosses the public ring. Every response is either public vocabulary or a public-safe…
Read →
Public API vs partner API: which one do you need?
Pick the public ring when you only need published figures — products, quotes, loyalty tiers. Pick the partner ring when you need…
Read →
Rate limiting across both rings
The public ring is metered at 60 requests per 60 seconds per IP. The partner ring uses a token bucket scoped to your project with…
Read →
Response envelopes and shapes
Every public-API response follows a predictable shape, so parsing is simple. Reads return a resource object (often with a…
Read →
Scopes and least privilege on partner/v1
Request only the scopes your integration actually uses. A credential scoped to applications:write cannot read decisions or move…
Read →
Security best practices for integrators
Five habits keep an integration safe: guard the secret, scope narrowly, verify every webhook, TLS everywhere, and rotate on a…
Read →
Security model of the public ring
An unauthenticated ring can be secure — here is exactly how this one is. With no credential to lean on, the public ring stacks…
Read →
Testing your integration
Test in layers: smoke-test the public ring, build against the sandbox, simulate webhooks and errors, then gate your release on…
Read →
Testing your public-API integration
Test your integration confidently without a special sandbox. The public reads change nothing and carry no PII, so you can assert…
Read →
The Credicorp MCP server
Credicorp runs an MCP server at /public/v1/mcp — JSON-RPC 2.0 over HTTP exposing the product catalogue, quotes, eligibility,…
Read →
The Credicorp MCP server, explained
The Credicorp MCP server lets an AI agent read public business-lending facts as tool calls. It speaks the Model Context Protocol…
Read →
The Credicorp public API, end to end
The /public/v1 ring is Credicorp's unauthenticated, read-mostly surface — product figures, quotes, the loyalty ladder, an MCP…
Read →
The MCP tool catalogue in depth
The public MCP server exposes six read-only tools. Together they let an agent answer almost any question about Credicorp…
Read →
The access-token lifecycle
A partner access token is minted, cached, reused until just before expiry, then re-minted. There is no refresh token in the…
Read →
The partner API, at a glance
The /partner/v1 ring is the token-gated integration API — take applications, read decisions, provision payments and run identity…
Read →
The partner MCP server
There are two MCP servers. The public one on /public/v1/mcp needs no token and exposes published figures. The partner one on…
Read →
The public /public/v1 ring, explained
The /public/v1 ring is the unauthenticated, anonymous surface of the Credicorp API. It exposes exactly the things a website,…
Read →
Versioning and deprecation policy
Both rings are versioned in the path (/public/v1, /partner/v1). Additive changes ship within a version; breaking changes get a…
Read →
Versioning and stability of the public API
The v1 in /public/v1 is a stability contract. Within a major version the platform adds fields and endpoints but does not remove…
Read →
Webhooks and event delivery
Credicorp pushes events — decision made, payment settled, document signed — to your registered URL as signed POSTs. Verify the…
Read →
Webhooks explained
A webhook is an HTTP callback Credicorp sends to your server when something happens — an enquiry is received, a decision is…
Read →
What you can build without a token
You can ship real products with no token at all: a live quote widget, a comparison listing, a loyalty display, and a…
Read →
Why the figures reconcile across the estate
Every Credicorp figure — on the site, in the API, through the MCP tools — comes from one source: the pricing config. That…
Read →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.