Skip to main content
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.
Bill Payment lives on 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

The X-Access-Token header was not sent.
What to do: add the header. Bill Payment accepts the key in that header only — never in a query string or a request body.
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.
We could not verify your key in time. Your key is not the problem.
What to do: wait for the Retry-After header (5 seconds) and retry. Never surface this to your customer as an invalid-credentials error, and never disable the key because of it.
The Bill Payment API is in planned maintenance.
What to do: honour Retry-After and retry.

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.
A sandbox key and a production key are interchangeable in shape but not in effect. A production key moves real money on the first successful payment. Verify key.type before you enable the payment path.

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.

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