Getting started

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 serverless function, or when you need total control.

2 min read

SDKBatteries included

Raw HTTPFull control

Same APIUnder both

What an SDK gives you

A Credicorp SDK wraps the same REST surface but handles the tedious parts: minting and caching OAuth tokens, retrying with back-off on 429/5xx, threading cursors, and giving you typed request and response objects. For most integrations it is the faster, safer path — you write business logic, not plumbing.

When raw HTTP wins

Reach for plain HTTP when there is no SDK for your language, when you are in a constrained runtime (a tiny serverless function, an edge worker) where a dependency is costly, or when you need behaviour the SDK does not expose. The API is deliberately simple — JSON in, JSON out, bearer auth — so raw calls are entirely reasonable. Everything on this portal documents the wire format directly.

You can mix them

Nothing stops you using an SDK for the heavy partner flows and raw HTTP for a one-off public read — they hit the same endpoints. Whichever you choose, the contracts on this portal (paths, params, errors) are authoritative.

Frequently asked questions

Do the SDKs support the public ring too?

Yes. The SDKs cover both rings — the public read endpoints and the token-gated partner endpoints. For a single public read, raw HTTP is often simpler; for partner flows, the SDK's auth and retry handling earns its keep.

Is raw HTTP officially supported?

Yes. The API is a plain JSON-over-HTTP contract documented here in full. SDKs are a convenience layer, not a requirement — raw calls are a first-class way to integrate.