Evaluate BillerAPI
One page, three separate ways to evaluate. Each branch below is a different availability state, so pick exactly one and follow it end to end. Mixing steps from two branches is the most common way an evaluation stalls.
Every branch ends at the same proof: an authoritative normalized bill you did not hand-write, and a signature-verified webhook that announced it.
This page makes no timing promise
Pick one branch
| Branch | What you need | Primary action | Fallback |
|---|---|---|---|
| Account-free | Nothing | Create a claimable sandbox with one unauthenticated request | Read the machine-readable contract instead of running it |
| Owned account | An email address | Sign up in the Client Portal and use the sandbox key minted with the account | Claim a sandbox you already created account-free |
| Consented agent | A human who keeps identity, consent, and production access | Give the agent the read-only public contract | The human runs a branch above and hands over a sandbox key only |
Each branch has exactly one primary action and exactly one fallback. If the primary action is unavailable to you, take that branch's fallback rather than switching branches mid-flight.
Branch 1 — Account-free
No signup, no email, no key of your own. Creating a claimable sandbox is a public route: it mints a sandbox client with its own bak_test_ key plus a one-shot claim URL you can redeem later.
Primary action
curl -X POST https://sandbox.api.billerapi.com/v1/sandboxes \
-H "Content-Type: application/json" \
-d '{}'The response carries sandbox_api_key and claim_url exactly once and neither value can be recovered afterwards, so store both before you continue. Use the key as a Bearer token against the sandbox host, then continue from the SDK install step of Getting Started.
Fallback
If you cannot make an outbound request yet, read the contract instead of running it. Every docs page serves its raw Markdown when you append .md to the URL, and llms.txt indexes the whole corpus. That fallback needs no key, no account, and no write of any kind.
The claim URL is a capability, not a link to share
The command-line entry points are not published yet
Branch 2 — Owned account
Take this branch when you want a durable account, a key you can rotate, and a path to production later.
Primary action
Sign up in the Client Portal. Signup signs you in and mints a sandbox bak_test_ key immediately, and Getting Started walks the rest of the path from that key.
Fallback
If you already ran Branch 1, open the one-shot claim URL from that response instead of signing up cold. Claiming attaches the existing sandbox and everything already in it to your new account, and the sandbox keeps its client id while its key is rotated.
Email verification gates production, not sandbox
Branch 3 — Consented agent
An agent may read the public contract on its own. It may not become you. The human keeps identity, legal acceptance, key custody, and production access, and grants the agent one narrow scope at a time.
Primary action
Point the agent at the machine-readable surface: llms.txt for the index, any page's .md variant for that page's full text, and openapi.json for the wire contract. That surface is read-only and needs no credential, so an agent can summarize the public biller catalog and the error taxonomy without ever acting as you.
Fallback
When the agent has to execute something, narrow the work rather than widening its authority. Run Branch 1 or Branch 2 yourself, then hand the agent only the bak_test_ sandbox key. Keep the claim URL, your password, and every production key out of the agent's context.
Consent is never delegated
The hosted agent plane is not enabled yet
Where an evaluation ends
The proof is server-side rather than a screenshot, and it is the same three stages on every branch:
- Sandbox proof — an authenticated call returns a resource your own key owns.
- First normalized bill — a bill lands on a linked sandbox account in the normalized shape, and you did not write it.
- Signed webhook — your endpoint receives that bill's event and signature verification accepts it.
The Webhooks guide covers the signature scheme and the webhook delivery concept page covers the retry schedule.
Not part of an evaluation today
- Payment execution. Pay endpoints answer
501 PAYMENT_EXECUTION_NOT_AVAILABLEand create no payment attempt, so model the flow but build no fulfillment against it. - Operator-driven webhook replay. No console control re-sends an already-delivered event. Reconcile with bill sync rather than waiting for a redelivery you cannot trigger.
- Real-time support during evaluation. Report anything wrong through docs feedback; no staffed interactive channel is offered with evaluation.
Next Steps
- Getting Started — The full walkthrough every branch converges on
- Choose an Integration — Map an outcome to the right API surface once you have a key
- Environments — Sandbox and production hosts, keys, and prefixes
- Go Live — What production access requires beyond a working sandbox