How to use your test environment for integration testing, plus known constraints and differences from production.
Storefront provides a full test environment for integration testing — a sandboxed instance of your store where you can safely develop and test your API integration before pointing it at production.
How the test environment relates to your API integration
The test environment mirrors production functionality. Anything you can do against the production API, you can do against the test environment, without affecting live data, live customers, or real payments.
The test environment uses a separate base URL and token endpoint from production:
| Environment | Base URL | Token URL |
|---|---|---|
| Production | https://api.shopco.com/v1 | https://auth.shopco.com/oauth2/token |
| Test | https://api.test.shopco.com/v1 | https://auth.test.shopco.com/oauth2/token |
API credentials are environment-specific, matching the UI-side test environment's separate login. You'll need to generate a separate Client ID/Secret pair for the test environment — the same credentials used against auth.shopco.com won't work against auth.test.shopco.com.
See Getting started for the full authentication flow.
Data isolation
Data created in the test environment — customers, DNS records, and so on — is isolated from your live Storefront. Nothing you do against the test environment affects production data, and nothing in production appears in test.
Test environment data does not reset or expire. Anything you create persists indefinitely, the same as production.
Webhooks in the test environment
Production and test run as fully independent applications, including for webhooks. If you configure a webhook subscription in the test environment, test activity triggers webhook deliveries the same way it would in production.
Use a separate endpoint for testIf you point a webhook subscription at your production endpoint while testing, your live systems will receive notifications for test activity. Configure a distinct test endpoint before testing webhooks, and remove or pause any test subscription pointed at a production URL.
Rate limits
The test environment enforces the same default rate limit as production: 600 requests per minute.
Feature and TLD parity
A small number of TLDs — including .FR, .MX, and .SE — are only available in production and can't be tested in the test environment. This list may not be exhaustive; if a TLD you need isn't behaving as expected in test, check with support before assuming it's an integration issue on your end.
Related articles
- Using the Test Environment — for testing through the Storefront Manager and customer-facing storefront UI, rather than the API directly