Learn how to manage different environments for your mock APIs, allowing you to test across development, staging, and production.
Open Project Settings → Environments to create named environments (development, staging, production) and configure per-endpoint overrides for each one.
Select which environment applies to a request by adding ?env=<slug> to the request URL, or by sending an X-Mock-Env header (shared links).
Environments allow you to define sets of variables and configurations that can be applied to your mock endpoints. Instead of changing individual endpoints, you switch the active environment.
They make your mock APIs more flexible and realistic. You can simulate production constraints, test different data sets, or point your frontend to different backend services instantly.
In the endpoint editor, define a different mock response, status code, or delay for each environment. The mock executor applies the override that matches the active environment automatically.
Add ?env=<slug> to the request URL, or send an X-Mock-Envheader when calling a shared endpoint. Requests with no environment specified use the endpoint's default response.
You can already store key-value variables per environment in Project Settings → Environments. What isn't built yet: automatically substituting those variables into response bodies. Today, use per-endpoint overrides above to vary a response by environment.
Once variable injection ships, environment variables will be accessible in response templates using double curly braces:
This syntax isn't implemented yet. Use per-endpoint overrides today for environment-specific response differences.
