Developer Docs
Authentication
One key per environment, sent on every request.
Every KreedX API authenticates the same way, so once one call works, the rest of the catalogue does too.
Sample guide
This shows how it works across our APIs. Exact header names, values and any extra steps are confirmed with your sandbox credentials.
How access works
Keys are issued to a known business after the first call with our team — they are not self-serve yet. You receive two sets:
| Environment | Used for |
|---|---|
| Sandbox | Building and testing. No real money moves. |
| Production | Live traffic, issued after your integration is reviewed. |
📘 The two never mix
A sandbox key sent to production — or the other way round — is refused with
401 UNAUTHORIZED. If a call that worked yesterday suddenly returns 401, check which environment the key belongs to first.Sending your key
Every request carries these headers:
| Header | Value |
|---|---|
| Authorization | Bearer <your API key>. Sandbox and production keys are separate. |
| Content-Type | application/json on every request that has a body. |
Example · cURL
curl -X GET "$KREEDX_BASE_URL/v1/bbps/billers?category=ELECTRICITY&page=1" \
-H "Authorization: Bearer $KREEDX_API_KEY"Keeping keys safe
Your API key can move money. Treat it like a password to your bank account.
- Call KreedX only from your server. Your web or mobile app talks to your backend, and your backend talks to us.
- Never put a key in browser JavaScript, a mobile app bundle or a Git repository — anything shipped to a user's device can be read.
- Keep keys in environment variables —
KREEDX_API_KEYandKREEDX_BASE_URLin our samples. - Give production keys only to the systems and people that need them.
🚧 If a key leaks
Tell our team straight away so the key can be revoked and a new one issued. Deleting the commit is not enough — the key stays in the repository's history.