Recipe

Move from the public API to the partner API

When you need accounts, offers or payments, you have outgrown the public ring. The public API is for reads and safe submissions; anything per-customer or money-moving lives behind authentication. This is the signpost: what stays public, what triggers the move, and where the partner API docs live.

2 min read

publicReads + safe submits
partnerAccounts, offers, money
OAuth2Auth for the step up

What stays on the public ring

Product data, the loyalty ladder, published pages, the support widget, the MCP server, enquiry submission and cookie consent — all public, all keyless. If your integration only ever touches these, you never leave the public ring.

What triggers the move

The moment you need to read a specific customer’s account, create or accept an offer, or move money, you are past the public ring. Those operations require an authenticated actor and, for partners, OAuth2 and request signing.

Where to go

The partner API reference and its authentication docs (OAuth2, request signing) cover the authenticated surface. Keep your public-ring integration exactly as it is — the two coexist.

Frequently asked questions

Can I do a real application on the public ring?

No. Applications, offers and payments require authentication and live on the partner/internal surface. The public MCP tools can explain how to apply but cannot do it.

Do I have to rewrite my public integration to add partner features?

No. The public and partner surfaces coexist. Keep your public-ring code and add authenticated partner calls alongside it.

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.