Skip to main content
Going live is a key swap. The same calls run against https://api.bachs.io with an sk_live_ key instead of https://sandbox-api.bachs.io with sk_sandbox_. Sandbox and production are isolated, so nothing crosses over: not accounts, not balances, not keys. What changes is that everything is real. Verification is checked against real records, capabilities are enabled by a real reviewer, and a transfer moves real money that cannot be reversed.

​
Before your first account

1

Confirm connect is active in production

Your sandbox capability says nothing about production. Check your live account:
capabilities.connect.status has to be active. See Become a platform.
2

Scope your production keys deliberately

A production key needs connected_accounts:write to create accounts, transfers:write to move money, and payouts:write to withdraw. Grant what the integration uses and no more. See Authentication.
3

Point your webhook endpoint at production and set event_source

Endpoints do not carry across environments. Create the production endpoint with event_source set to connect or all, or you will receive nothing about your accounts. See Monitor onboarding.
4

Verify your signature check against a live delivery

Signing secrets are per endpoint, so the live endpoint has a different one. A verification step that silently passes in sandbox and fails in production is the most common go-live failure.

​
Before you move money

  • Trigger transfers on settlement, not on the charge succeeding. This works in sandbox where balances settle quickly and fails in production where they do not. See Balances.
  • Send an Idempotency-Key on every transfer and withdrawal. A retry without one pays twice.
  • Never treat a 5xx as a failure. Read the current state before retrying.
  • Decide when you transfer a seller’s share. Once it is transferred and withdrawn, a reversal cannot recover it. See Split payments.

​
What does not change

The API surface is identical. Requests, response shapes, requirements, transfers, and withdrawals all behave the same way, so an integration that works end to end in sandbox works in production.

​
What does change

Capability grants do not. In sandbox, a capability whose persona the account has applied is granted active at creation, with no review. In production, the same request lands the capability restricted, and it only reaches active once a reviewer enables it after the account’s requirements are complete. An integration that assumes a capability is usable immediately after creation, because that is what it saw in sandbox, will find it restricted in production until review finishes. See Testing for exactly what sandbox grants and what it does not.