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.

Pick one branch

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. The claimable-sandbox route is public, and production refuses it today: account-free creation ships fail-closed until per-sandbox quotas land, so the request below answers 501 NOT_IMPLEMENTED on both hosts. Where the switch is on, the route mints a sandbox client with its own bak_test_ key plus a one-shot claim URL you can redeem later. For a key you can use right now, take Branch 2.

Primary action

curl -X POST https://sandbox.api.billerapi.com/v1/sandboxes \
  -H "Content-Type: application/json" \
  -d '{}'

Where creation is enabled, 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.

Creation is served on the sandbox host and on the production host alike, so the whole sequence on this page — create, link, bill, proof — runs against one host. Both answer 501 NOT_IMPLEMENTED while the switch is off, as they do today, and the answer comes from the same switch rather than from each host's own opinion.

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.

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.

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.

Where an evaluation ends

The proof is server-side rather than a screenshot, and it is the same three stages on every branch:

1. Sandbox proof — an authenticated call returns a resource your own key owns.
2. First normalized bill — a bill lands on a linked sandbox account in the normalized shape, and you did not write it.
3. 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_AVAILABLE and 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