Public API

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 server-fixed response shapes, changes only additively within v1, and degrades gracefully when a feature is off. Understanding them lets you write an integration that stays correct as the platform evolves.

2 min read

5Core principles
stableAdditive only
gracefulDegrades cleanly

Keyless by default

Nothing on the public ring is per-caller, so there is no key or token to manage. Protection comes from rate limiting, validation and fixed shapes instead. See authentication on the public ring.

PII stays private

No per-customer personal data ever crosses the ring. Responses are public vocabulary or public-safe projections; sensitive fields are structurally absent, not masked. See Privacy and PII.

Server-fixed shapes

The server sets privileged fields itself — an enquiry’s status, a biller response’s omitted bank data — so a caller can never smuggle in a value it should not control.

Additive change

Within v1, fields and endpoints are added but never removed or repurposed. Write tolerant parsers and you keep working. See Versioning and stability.

Graceful degradation

Flag-gated endpoints return a clean empty state when off, not an error. Call them unconditionally and render nil gracefully. See Feature flags.

Frequently asked questions

Will these principles change?

They are the stable contract of the public ring. Additive change within v1 is expected; the principles themselves are what let you rely on it.

Why no API key at all?

Because nothing on the public ring is per-caller. A key would add a secret to leak while protecting nothing. Keys live on the authenticated partner surface.

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.