How to Host a Shareable Cloud Mock Server with Apidog

Your frontend team is blocked: the design is approved, screens are partially built, and the backend API is still a sprint away. A local mock may unblock you temporarily, but it disappears when the machine hosting it goes offline—breaking teammates, QA, and partners who depend on that endpoint.

Try Apidog today

Apidog Cloud Mock provides a hosted URL at mock.apidog.com that remains available independently of your laptop. Frontend, QA, and partner developers can call realistic endpoints before backend implementation is complete. For more background, see what an API mock is and when to use one and MDN’s HTTP request/response overview.

What Cloud Mock solves

Apidog generates a mock endpoint for every API endpoint you define. By default, that mock is local: it runs through your Apidog instance and stops responding when your machine is offline.

That is useful for individual debugging, but it does not work as a shared integration environment.

Cloud Mock hosts the mock independently of any developer machine. Once enabled, the endpoint stays available 24/7, even if every teammate closes Apidog.

Use it to create a shared contract-first workflow:

1. Define the endpoint and response schema.
2. Enable Cloud Mock for the project.
3. Share the generated URL with frontend, QA, or partners.
4. Let consumers build and test against the contract while backend work continues.

For distributed teams, see sharing mock servers and environments with global teams.

Enable Cloud Mock and get a public URL

Assume you are designing a users service with this endpoint:

GET /users

The endpoint should return a list of customer records. Here is how to make it available as a shared cloud mock.

Step 1: Enable Cloud Mock

In your Apidog project, open:

Project Settings > Feature Settings > Mock Settings

Enable Cloud Mock.

You only need to do this once per project. After Cloud Mock is enabled, endpoints in that project have a cloud mock URL in addition to their local mock URL.

Step 2: Copy the Cloud Mock URL

Open GET /users, then select the Mock tab. Copy the Cloud Mock URL.

It will look similar to this:

https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi

The URL generally follows this structure:

mock.apidog.com/m1/<projectId>-<num>-<env>/<path>

Do not construct these URLs manually. Copy the URL generated by Apidog, since the documentation presents the format by example rather than as a fixed public template.

Step 3: Validate the response in Apidog

Before sharing the endpoint, test it from the same Mock tab.

Send a request to the mock URL and verify that the generated data matches your schema. For example, a GET /users response might look like this:

[
  {
    "id": 1,
    "name": "Amelia Turner",
    "email": "[e-mail]",
    "city": "Portland"
  },
  {
    "id": 2,
    "name": "Marcus Bell",
    "email": "[e-mail]",
    "city": "Austin"
  }
]

Apidog uses the field names and types in your schema to generate plausible values. This lets frontend developers work with data that better resembles production responses than placeholder values such as "string".

Step 4: Call the URL from your app

For GET endpoints, paste the full Cloud Mock URL into a browser to quickly inspect the JSON response.

Your frontend can call it like any API endpoint:

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"

That is the core workflow:

1. Design the endpoint.
2. Enable Cloud Mock.
3. Copy the hosted URL.
4. Share it with consumers.

Protect Cloud Mock with token authentication

A public mock URL is convenient, but you may not want unrestricted access to mocks for unreleased features or partner integrations.

To require authentication, open:

Project Settings > Feature Settings > Mock Settings

Set the access permission to Token Authentication.

Once enabled, requests must include a valid apidogToken. Requests without one are rejected.

Option 1: Send the token as a query parameter

The copied Cloud Mock URL already uses this format:

curl "https://mock.apidog.com/m1/2689726-0-default/users?apidogToken=GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"

Option 2: Send the token as a request header

Using a header keeps the token out of the URL and reduces the chance of exposing it in URL logs or browser history.

curl "https://mock.apidog.com/m1/2689726-0-default/users" \
  -H "apidogToken: GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi"

For frontend code, this is usually the cleaner option:

const res = await fetch(
  "https://mock.apidog.com/m1/2689726-0-default/users",
  {
    headers: {
      apidogToken: "GdfNrEm6lxM9nDGGIMCWC1OPSiZ6hGOi",
    },
  }
);

const users = await res.json();

Option 3: Send the token in a form body

You can also provide apidogToken as a body parameter in a form-data or x-www-form-urlencoded request.

If you enable token authentication after sharing an unauthenticated URL, coordinate the change with all consumers. They must update their requests with the token before calls begin failing.

Generate region-aware mock data with locales

Mock responses such as this are rarely useful:

{
  "name": "string"
}

Realistic names, addresses, phone numbers, and timestamps help teams find UI issues early, including:

• text overflow
• address formatting assumptions
• non-Latin character rendering
• timestamp localization issues
• table and card layout problems

Apidog uses Faker.js for generated mock data and supports locale controls.

Use the project language as the default locale

By default, generated data follows the project language configured in:

Project Settings > Basic Settings

For example, setting the project language to French makes generated names and addresses French-flavored without configuring each field individually.

Override the locale for the entire project

To use a locale different from the project language, open:

Project Settings > Feature Settings > Mock Settings

Choose a Faker locale from the locale dropdown.

This setting overrides the Basic Settings language for all mock values in the project.

For example, setting the project mock locale to Japan can help you test names, addresses, and scripts that differ from English-language data. For more on schema-driven generation, see Apidog’s smart mock and how it reads your schema.

Override the locale for one field

For mixed-region datasets, set the locale directly in a mock expression:

{{$person.fullName(locale='ja')}}

This generates Japanese names, such as 田中 太郎, for that field while other fields continue using the project-level locale.

The precedence order is:

1. Field-level locale
2. Project-level mock locale
3. Basic Settings language

Use the project-level setting as the default, then add field-level overrides only where needed.

The documentation uses ja as an example but does not publish a complete locale list. Confirm your target locale in the Apidog mock documentation before depending on it. Faker’s locale conventions are documented in the Faker.js localization reference.

Configure time zones too

Mock settings also include a project-level time zone control. You can override the time zone per field with the timeZone parameter in a mock expression.

Use this when generating fields such as createdAt, updatedAt, or scheduled event timestamps. It helps ensure mock timestamps match the region your UI is simulating.

Combined locale and time-zone settings let you model a Japanese user base, a German user base, or a mixed international dataset from the same API schema. See practical API mocking use cases for additional scenarios.

Cloud Mock vs. self-hosted mock servers

Cloud Mock is the hosted option. It is useful when you want a shared endpoint without running infrastructure yourself.

Use a self-hosted mock service when your organization has requirements such as:

• data residency restrictions
• internal-only test environments
• policies against routing test traffic through a vendor cloud

The trade-off is simple:

Option	Best for	Trade-off
Cloud Mock	Fast setup and always-on shared URLs	Hosted by Apidog
Self-hosted mock	Infrastructure and traffic control	You operate the service

For self-hosting details, see self-hosting the Apidog mock server. For a broader comparison, see online API mocking tools.

The Cloud Mock and locale documentation does not state a specific plan requirement. Check availability in your workspace rather than relying on a blog post for plan details. You can Download Apidog and test the workflow in your account.

Keep mock contracts current with the Apidog CLI

Cloud Mock itself is a hosted capability: Apidog generates responses from your endpoint schema and serves them through its hosted mock engine.

The Apidog CLI does not start or host a mock server. Its role is to help keep the API definitions that drive your mocks accurate.

A practical workflow looks like this:

1. Create or update endpoint schemas in your project.
2. Let Cloud Mock generate responses from the updated schema.
3. Build frontend features against the mock URL.
4. Implement the backend against the same contract.
5. Run saved API test scenarios against the live backend in CI.

When an AI coding agent such as Cursor or Claude Code updates an endpoint schema, the Cloud Mock response can reflect the changed contract without manually editing mock payloads.

Once the real backend is available, run a saved Apidog scenario from the CLI:

apidog run -t <scenario_id> -e <env_id> -r cli

This command runs a saved test scenario against an environment and reports the results.

Copy the generated command from your Apidog scenario instead of assembling -t and -e values manually. For pipeline integration, see running Apidog in a CI/CD pipeline.

FAQ

Does the Cloud Mock URL work after I close Apidog?

Yes. Cloud Mock is served from Apidog’s infrastructure, so it remains available 24/7 even when your computer is offline.

Can I open a Cloud Mock URL in a browser?

For GET requests, yes. Paste the full URL, including the apidogToken query parameter, into the browser to view the JSON response.

For other HTTP methods—or to avoid exposing tokens in URL history—use curl, Postman, Apidog, or your application client and send the token as a header.

What happens when a request does not include the token?

When Token Authentication is enabled, requests without a valid apidogToken are rejected.

Provide the token through:

• a query-string parameter
• a request header
• a form request body parameter

How do I generate mock data for a specific country?

Choose one of these levels:

1. Set the project language in Basic Settings.
2. Set a project-wide Faker locale in Feature Settings > Mock Settings.
3. Set a field-level locale in a mock expression.

For example:

{{$person.fullName(locale='ja')}}

Field-level settings override project-level settings, and project-level settings override the Basic Settings default. See the smart mock walkthrough for schema-aware generation details.

Should I use Cloud Mock or a headless mock tool?

Use Cloud Mock when you need a hosted, low-maintenance endpoint connected to your API design.

If you need mocks embedded in an automated build with no GUI workflow, review headless API mock tooling. Most tools in this space build on API contracts, often using the OpenAPI Initiative specification.

Wrapping up

A mock that runs only on your laptop unblocks one developer. Cloud Mock creates a shared mock.apidog.com endpoint that frontend developers, QA engineers, and partners can use while backend implementation is still in progress.

Use Cloud Mock to:

• share a stable mock URL
• protect endpoints with token authentication
• generate locale-aware test data
• keep frontend work moving from the API contract
• validate the eventual backend with tests tied to the same project

Define the endpoint, enable Cloud Mock, share the URL, and let frontend work continue without waiting for the backend. Download Apidog to create your first shareable cloud mock.