Concepts

Sandbox environment

Test Qboxmail Management API workflows safely before using production resources.

The Qboxmail sandbox is a separate environment for testing the Qboxmail panel and Management API without affecting real domains, mailboxes, or Delivery settings.

Sandbox is for Management API only

The sandbox is available for Management API testing. It does not support Send API endpoints such as /v1/send or /v1/send/bulk.

Request sandbox access

You can request sandbox access from the Qboxmail website: Request Sandbox access.

After you send the form, Qboxmail creates your sandbox access and sends the details by email. The team may also contact you by phone or email to explain how the environment works.

Sandbox vs production

Sandbox resources are separate from production.

EnvironmentAPI hostUse it for
Productionhttps://api.qboxmail.comReal customer data and services
Sandboxhttps://sandbox.qboxmail.comManagement API tests, experiments, and integration development

To call a Management API endpoint in sandbox, replace the production host with the sandbox host.

curl "https://sandbox.qboxmail.com/api/domains" \
  -H "X-Api-Token: <SANDBOX_API_TOKEN>"

Billing and Delivery behavior

Sandbox is meant for testing Management API workflows, so it does not require a production billing profile or a completed first order.

You can use sandbox credentials to test resource setup flows, such as creating Hosting domains, mailboxes, Delivery domains, Delivery accounts, API tokens, and suppression-list entries.

Sandbox Delivery is configuration-only

Delivery resources created in sandbox are for configuration and Management API testing. They are not production sending resources, they do not prove that production sending is ready, and you cannot use them to send email with the Send API.

Data cleanup

Use sandbox for disposable domains, mailbox provisioning, and general API experiments. It is not permanent: sandbox resources are cleaned up every Sunday at 03:03 CEST. If something disappears, rerun the flow to recreate it.

Do not store sandbox resource IDs or codes in permanent configuration, and do not use sandbox data as a reference for production.

Best practices

  • Use separate sandbox credentials and tokens.
  • Test operations that delete or change data, provisioning flows, and error handling in sandbox first.
  • Keep sandbox and production configuration clearly separated in your application.
  • Move to production only after the full workflow has been tested with production credentials, production domains, and the correct DNS configuration.

On this page