Creating and Configuring Mocks

Overview

This guide follows the API Mocks experience in the product: open Mocks from the top navigation, select a project, then create, generate, start the server, and manage mocks in the project table.

Conceptual background: Understanding mocks.

Open API Mocks

1. From the main screen, select Mocks in the top navigation (Mocks is highlighted when active).
2. The API Mocks page opens with a short description: mocks can replace real API calls during test execution or run as a standalone server.
3. Scroll to Select a project and choose a project card (for example Pet Store or Calc).
4. The Mocks view for that project opens (you can use All projects or an equivalent control to go back and pick another project).

Actions

In the header area for the selected project you will typically see:

• Start Mock Server — Start the mock service so callers can reach your mocks at the displayed base URL/host (stop or restart when your deployment provides it).
• Create Mock — Manually define a new mock (method, path, responses).
• Generate Mock — Create mocks from your API definition or endpoints (for example OpenAPI-driven generation), then review and save.
• Project settings — Open project configuration when shown (gear or Project settings).

Create a mock manually

1. Select Create Mock.
2. Link the mock to an endpoint (or define method and path), and set feature grouping if the UI offers it.
3. Configure responses:
   • Static — fixed status, headers, and body (for example JSON).
   • Dynamic — templates, variables, or conditional behavior where supported.
4. Save. The new row appears in the mocks table with Active or Inactive status depending on defaults.

Generate mocks

1. Select Generate Mock.
2. Choose scope (endpoints, feature, or spec-driven options your build exposes).
3. Review generated definitions and adjust response bodies, status codes, or conditions.
4. Save. Generated mocks appear in the same list as manual mocks.

Configure responses (summary)

• Status code — for example 200, 201, 400, 404.
• Headers — such as Content-Type.
• Body — static JSON/text or dynamic template.
• Conditions — different responses for different request inputs when supported.
• Delay — optional latency to exercise timeouts (if available).

Use test with sample request (or the row Play action) to validate before broad use.

Manage the mocks table

Toolbar:

• Search mocks — filter by name, path, or other visible text.
• Grouping — organize rows (for example No grouping or by feature).
• Columns — show or hide columns.
• Count — for example Showing 8 of 8 mocks.

Typical columns:

• Status — Active or Inactive.
• Mock name — title plus a short description line.
• Feature — tag or grouping (for example pet).
• Endpoint — HTTP method badge and path.
• Type — static or dynamic.
• Responses — number of configured responses for that mock.
• Created — timestamp.

Row actions (icons may vary slightly by version):

• Play — run or test the mock with a sample request.
• Power / toggle — switch Active vs Inactive without deleting the mock.
• Edit — change definition and responses.
• Delete — remove the mock (confirm when prompted).

Standalone server and test runs

• After Start Mock Server, point consumers (apps, scripts, or test configuration) at the mock base URL shown in the UI.
• For test execution, ensure your project or run configuration is set to use mocks when your deployment supports automatic mock routing.

Related articles

• Understanding mocks
• Endpoint management
• Test execution