Go-live checklist

Moving from sandbox to production is self-service: the portal walks you through three automated gates, and once they pass, production unlocks without waiting for a human. This page covers the gates and — more importantly — what your integration should get right before real users hit it.

The three gates

Open Settings → Go live in the partner portal:

1. Payment card verified. Production usage is metered and billed monthly; a verified card is required for self-service billing.
2. Business check. Automated for Czech companies (IČO registry lookup) and EU VAT payers (VIES). Non-EU companies, or lookups that fail, go to a short manual review — you'll see the state in the portal.
3. Terms accepted. The current Terms of Service and Data Processing Agreement, accepted by an org admin (versioned and logged).

All green → production is active, and the API keys page lets you mint bb_live_… keys. Your code stays identical; only the key changes.

Integration readiness

The gates check your account; this list checks your code.

Webhooks — see the verification guide:

• Configure a live-mode webhook endpoint (webhook config is per mode — your sandbox URL keeps working for sandbox).
• Verify X-BB-Signature over the raw body bytes, against all active secrets (two during rotation), with constant-time comparison — the official SDKs do this for you.
• Respond 2xx to every verified delivery, including unknown event types — new types appear without notice, and non-2xx responses trigger redelivery.
• Deduplicate by eventId: delivery is at-least-once.

Error handling — see the error reference:

• Branch on error.code only; never parse messages.
• Honor Retry-After on 429; back off on 5xx.
• Send Idempotency-Key on creates so retries can't double-create (automatic in the official SDKs).

API keys — see Authentication:

• Keys live only on your servers, in a secret manager.
• Mint separate live keys per environment of yours (staging vs production), so you can revoke one without touching the other.

Mobile return path (if you use the Link SDKs):

• Universal links / app links must verify against your production domain — check that apple-app-site-association / assetlinks.json are served there, not just on your staging host.
• Test the custom-scheme fallback and the "user closes the tab" path — you should land in your cancelled-handler, not hang.
• Treat the redirect as a UX signal; your backend confirms the result via the session state and webhooks (see the hosted connect flow).

Starter limits and the spending cap

New production partners start with conservative limits: a rate-limit tier, a connection cap, and a monthly spending cap — the current values are shown in your portal dashboard. The cap is a safety brake: when a month's usage reaches it, the API blocks (you and your org admins are notified and the portal shows a banner) until you raise the cap or the billing period settles. Ask us to raise limits as you grow — that's expected.

When something goes wrong

Every response carries an X-Request-Id header (and requestId in error bodies). Include it when writing to integration@budgetbakers.com — with it we can trace your exact request through the platform.