Going live checklist
Updated 13 September 20263 min read
On this page
Moving from the sandbox to live changes real balances, so do it deliberately. This checklist covers what has to be approved, what to switch and what to verify on the first day.
1. Get your business approved
You cannot create live keys until business verification (KYB) is approved. Reviews take 1 to 2 business days, up to 5 for enhanced due diligence, so submit early. You can finish your integration in the sandbox while the review runs.
2. Accept the agreement and choose a plan
The authorized signer accepts the Ledgerline agreement in the dashboard. Choose a plan that fits your volume and payout limits. Starter is free, so many teams go live on it and upgrade later. See Plans and pricing.
Pick your data region before you create the live organization data, because it cannot be changed afterwards without a migration. See Data residency and retention.
3. Switch the configuration
| Setting | Sandbox | Live |
|---|---|---|
| Base URL | https://sandbox.api.ledgerline.dev/v1 |
https://api.ledgerline.dev/v1 |
| API key | ll_test_sk_... |
ll_live_sk_... |
| Webhook endpoint | Sandbox endpoint | A separate live endpoint, with its own whsec_ secret |
| Counterparties | Test bank accounts | Real accounts, verified by micro-deposit or prenote |
Create live keys in the dashboard under Developers > API keys. Store them in your production secrets manager, and prefer restricted keys with an IP allowlist where your plan has one.
Keep the environments from leaking into each other: derive the base URL from the key prefix, or fail at startup if they disagree.
4. Pre-launch checks
- Every
POSTsends an idempotency key that is stable across retries. - Retries follow the backoff guidance and honor
Retry-After. - Webhook handlers verify the signature, deduplicate on
event.idand tolerate out-of-order delivery. - You handle
payout.failedandpayout.returned, not justpayout.paid. See Returns and failed payouts. - Your error handling branches on
error.code, with arequest_idlogged for each failure. - You stay under 600 requests per minute per key, with headroom. See Rate limits.
- Amounts are integers in minor units, including the zero-decimal yen.
- No keys are in source control or client-side code.
5. Verify bank accounts early
Real micro-deposits take 1 to 2 business days to arrive, unlike in the sandbox. Verify your own funding and payout accounts a few days before launch so the first payout is not blocked by counterparty_unverified.
Remember that the first payout above $25,000 to a counterparty younger than 7 days is held for review, usually for up to 4 business hours. Warn the people who will make the first payments.
6. Fund and test with a small amount
- Create a virtual account for your funding ledger account and send a small real payment to it.
- Wait for the
transaction.postedevent and confirm the balance. - Make a payout of a small amount to a bank account you control and watch it reach
paid. - Check the entry in your next reconciliation run.
7. Monitor from day one
- Subscribe to the status page so you know about incidents before your customers do.
- Alert on webhook delivery failures and rising 5xx counts.
- Track
Ledgerline-RateLimit-Remainingto spot a runaway job.
What does not carry over
Nothing in the sandbox is copied to live: not ledgers, accounts, counterparties or webhook endpoints. Create them again, ideally with the same script you used to set up the sandbox. Treat your setup as code so it can run against both environments.
Tip
Put the ledger structure (ledgers and accounts) in a version-controlled script that is safe to run twice, using external_id and idempotency keys. You will be glad of it when you add a second region.