Skip to main content
Create a Sandbox key in API Center and send it as a Bearer token. Sandbox secrets begin with sk_test_.
Sandbox calls still require the endpoint’s scopes, pass through the IP firewall, consume rate limits, update Last Used after successful authentication, and can appear in API logs. They do not change service, request, or invoice records.
Sandbox is not a separate, persistent test account. Generated services and requests are not saved. An identifier from a create response cannot be used to test a later state change.

​
What each operation returns

Most business responses include mode: "test" and simulated: true. Authentication checks identify the key mode as test instead. The plans endpoint returns the real broker catalog, without simulation markers.
  • Check authentication returns real broker and key metadata, including the real service count when the key has permission.
  • Check service-write access verifies the scope without creating a service.
  • List Plans returns your actual active catalog. Service creation validates against that catalog even in Sandbox Mode.
  • Create Service returns a generated request. Automatic approval also returns a simulated active service and test credentials. Manual approval returns a pending request.
  • List Services returns at most one generated service and applies status, search, modified_since, limit, and offset. Credentials require include_credentials=true and admin:full.
  • Get Service echoes the numeric service number and returns generated details and credentials without looking up a service.
  • Change Service Password validates the input and simulates an update, optionally generating a test password. It does not change a password or email a client.
  • Upgrade and Downgrade return accepted simulated requests. Unlike live plan changes, they accept the standard plan names/slugs only: Basic VPS, Standard VPS, Professional VPS, and Dedicated Server. Their simulated current plans are Basic VPS and Professional VPS respectively.
  • Cancel Service validates the reason and returns an accepted cancellation request without cancelling anything.
  • Send Cancellation Warning returns an approved simulated warning record without sending email or saving a request.
  • List Requests returns at most one generated request. It validates accepted filters and dates and applies search and pagination without reading real requests.
  • Manage Request simulates approval or denial. Approval returns a generated service number. Denial requires denial_reason. Neither operation changes records.
Services Report and Invoices Report return fixed totals and normalized recipient counts. The invoice response also includes the requested date range. Neither endpoint reads report data, creates a file, or sends email.

​
Test scenarios

Send the optional X-Test-Scenario header to select a simulated response. Values are case-insensitive. An omitted or unrecognized value uses the success scenario.
Authentication and catalog reads do not use these scenarios. Input validation can take precedence over the selected scenario. A request denial also takes precedence over nycservers_review.

​
Identifiers and limitations

Generated request IDs look like REQ-004219; generated service numbers have nine digits. Request management accepts REQ- followed by digits, case-insensitively, and normalizes the result to uppercase with at least six digits. Service paths accept numeric service numbers. Sandbox does not verify live record existence, ownership, or service state. It cannot test provisioning, email delivery, report attachments, persistent workflows, or live idempotency guarantees. List results and report totals are not representative of live data volumes. Timestamps use the time of the call, and generated identifiers can change between calls. Use a Live key only when you intend to perform real operations.
Last modified on September 8, 2026