Getting started

API keys & credentials

Century does not issue partner API keys today. Access is granted per user account through bearer tokens, and every provider secret stays on the server.

Current model

Publishable key — identifies the Century project to the auth service. Safe in frontend code.
Access token — per-user JWT, short lived, sent as a bearer header. This is what authorises API calls.
Provider secrets — Paystack, RapidBills, MySubWallet and BigiSub credentials live only in server environment variables and are never returned by any endpoint.

Self-service API keys: not implemented

There is no dashboard to mint, rotate or scope an API key, and no key-based authentication path on the server. Any integration guide that tells you to send x-api-key to Century is wrong.

Storing credentials

.env (server only)

CENTURY_URL=https://centuryvtu.com
CENTURY_PUBLISHABLE_KEY=pk_...        # safe to expose
CENTURY_SERVICE_EMAIL=ops@yourco.com  # never expose
CENTURY_SERVICE_PASSWORD=...          # never expose

Keep secrets in your platform's secret manager, not in source control.
Never log a bearer token, PIN, BVN or NIN — Century redacts these server-side and expects you to as well.
Rotate any credential the moment it appears in a screenshot, ticket or chat message.

Client-side safety

Inspection-proofing

Anything shipped to a browser can be read. Century keeps all money-moving logic, pricing, markups, provider routing and role checks on the server precisely because the client is untrusted. Mirror that in your own integration: put the token exchange and any secret on your backend, and let your frontend talk to your backend.

Need machine access?

If you need a service account or a scoped key for a genuine integration, reach out through developer support — access is granted manually and reviewed case by case.