Practice organization

The practice organization of the workspace

platform.sandbox.get

Returns the state of the practice organization that test keys (mbs_test_…) work on: whether it exists (it is created with the first test key), its id, when it was created, seeded and last reset, how many test keys of the workspace are active, and which operations that reach an external platform it simulates (the rest of those answer 409 sandbox_external_unavailable there). Called on the workspace or, with a test key, on the practice organization itself; on an Account it answers available: false with reason account_has_no_practice and its workspace in workspace_id. Owners and admins. Module: API & MCP (developer_platform), even though the id starts with platform.; the credential needs the developer_platform:read scope.

Scope

developer_platform:read

Permission

View the module · Only owner, admin

MCP tool

platform_sandbox_getOn the full surface; on the compact one, mb_execute_operation with id: "platform.sandbox.get".

Declared cost: up to 62 reads and 0 writes per call (they count against the daily quota).

Parameters

No parameters.

Response

Errors

Example

curl "https://api.mb-suite.com/v1/sandbox" \
  -H "Authorization: Bearer $MB_API_KEY"

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl "https://api.mb-suite.com/v1/sandbox" \
  -H "Authorization: Bearer $MB_TEST_KEY"

Reset the practice organization's data

platform.sandbox.reset

Deletes everything the practice organization (the one test keys work on) has accumulated —CRM records, trash, webhook events and deliveries, jobs and any other module data— and seeds the example data again: a CRM (a pipeline with its stages, companies, persons, deals in different stages and activities) and a few activity labels to try labeling entries. Test keys and the practice webhook subscriptions are kept, and so is the day's usage of the practice organization. It cannot be undone and nothing goes to the trash. Run it with dry_run first to see what will be deleted; when complete is false the call ran out of time, so run the dry run again and call it with the new confirm_token to finish (a confirm_token works once). Called on the workspace or, with a test key, on the practice organization itself. Owners and admins. Module: API & MCP (developer_platform), even though the id starts with platform.; the credential needs the developer_platform:write scope and permission to delete.

Needs confirmation: first dry_run: true (preview and confirm_token, valid 10 minutes and for one run), then the same body with confirm_token. In a few operations only with certain data: the description says when. Why and how: Dry run and confirm_token.

Scope

developer_platform:write and “Allow deletions” (developer_platform:delete in OAuth)

Permission

Edit in the module · Only owner, admin

MCP tool

platform_sandbox_resetOn the full surface; on the compact one, mb_execute_operation with id: "platform.sandbox.reset".

Declared cost: up to 500 reads and 548 writes per call (they count against the daily quota).

Parameters

No parameters.

Response

Errors

Example

curl -X POST "https://api.mb-suite.com/v1/sandbox/reset" \
  -H "Authorization: Bearer $MB_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "dry_run": true
}'

Try it with your test API key

With a test API key the request always goes to your practice organization: example data you can reset.

curl -X POST "https://api.mb-suite.com/v1/sandbox/reset" \
  -H "Authorization: Bearer $MB_TEST_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "dry_run": true
}'