Skip to content

Sandbox

A sandbox is a real OneBooks business owned by your organization — provisioned through the same tenant-creation path as a production signup, with a real chart of accounts and a real ledger. Nothing about it is mocked: an invoice you push into a sandbox posts genuine journal entries you can inspect in reports.

Create sandboxes from your org’s Sandbox tab in the developer console (org admins only). Each org can have up to 3 sandbox businesses at a time.

Creating a sandbox returns an owner login:

{
"businessId": "",
"businessName": "",
"ownerEmail": "sandbox-ab12cd34@sandbox.getonebooks.com",
"ownerPassword": ""
}

Use these credentials to:

  • Sign in to the OneBooks app at app.getonebooks.com — set up test customers, items and settings the way a real merchant would.
  • Complete the OAuth consent flow — when your app redirects to the authorization page, log in as the sandbox owner and approve. The resulting tokens are scoped to the sandbox business.

Sandboxes are how you develop before your app is approved:

  • An app that hasn’t passed review can only complete authorization against its own org’s sandbox businesses. Attempting to connect any other business fails with 400 — enforced server-side at both the consent step and the token exchange.
  • Once approved, the app can connect to any OneBooks business. Sandboxes keep working exactly as before — keep one around for regression-testing releases.

The review submission also asks you to confirm you’ve tested the integration end-to-end against a sandbox, so build that habit early.

Deleting a sandbox from the console immediately revokes its OAuth consents/tokens and owner sessions. Removal frees a slot toward the cap of 3.

  • Not anonymized production data. They start empty; you create the test data.
  • Not rate-limit exempt. The same limits apply.
  • Not a separate API. Same hosts, same endpoints, same webhooks — only the consenting business differs, which is exactly what makes sandbox testing representative.