Validate API Key
Bill Payment
Validate API Key
Confirm a Bill Payment key works and which environment it belongs to
GET
Validate API Key
Overview
Verifies your Bill Payment API key and echoes back who you are and which environment the key is bound to. It is the first call to make in a new integration and the safest way to prove, before you move any money, that you are pointed at sandbox rather than production.Each key is bound to exactly one environment —
SANDBOX or PRODUCTION. The environment is a property of the key we issue you. Never derive it from the text or the prefix of the key; read key.type from this endpoint.https://billapi.oneclickdz.com, not on the base URL used by the rest of the platform. The header is the same one you already use: X-Access-Token.
Response
boolean
required
true when the key was verified.object
required
object
required
string
required
Correlation identifier, also sent as the
X-Request-Id response header.Examples
Success Response
Error Responses
401 — Missing access token
401 — Missing access token
The What to do: add the header. Bill Payment accepts the key in that header only — never in a query string or a request body.
X-Access-Token header was not sent.401 — Invalid access token
401 — Invalid access token
The key was rejected.What to do: check for a copy-and-paste error, then contact support. Retrying the same key will not change the answer.
Confirming your environment before go-live
Run this check at start-up, and again in your deployment pipeline. A single line of output tells you whether the key in that environment’s configuration is the one you meant to ship.What this endpoint does not return
Bill Payment keys have no scopes, no expiry field and no per-key balance, so none of those appear here.account, key.type, meta and requestId are the whole response.
Best Practices
Call it at start-up
One call at boot proves the key works and names the environment, before any customer traffic reaches the payment path.
Never log the key
Log
account.id and key.type instead. The key itself belongs in a secret store, never in application logs.Separate the two keys
Keep the sandbox and production keys in different configuration stores so neither can be reached from the other environment.
Treat 503 as transient
AUTH_UNAVAILABLE means we could not answer in time. Retry after Retry-After; do not roll the key.Related Endpoints
List Partners
Check which partners are available
Discover Bills
Start a bill discovery
Bill Payment Overview
How the whole flow fits together
Sandbox Testing
Test every outcome before go-live

