# Understanding Mocks

> API mocks replace real backend calls during test runs or run as a standalone mock server—organized per project with static or dynamic responses across REST, SOAP, and GraphQL.

Source: https://totalshiftleft.ai/help-center/product-documentation/understanding-mocks

## Overview

**API mocks** let you create and manage fake responses for your API endpoints. In Shift Left Studio you can use them two ways:

- **During test execution**, so tests don't depend on live services.
- **As a standalone mock server**, so clients, tools, or teammates can call predictable responses outside a full test run.

Mocks are always scoped to a **project** — you pick a project on the **API Mocks** page, then create and manage mocks for that project's endpoints. This article covers what mocks are and how they behave. Explore the capability at [mock server](/features/api-protocols/mock-server).

## Before you begin

- This is a conceptual overview. For the click-by-click UI walkthrough — creating, generating, configuring, and serving mocks — see [Creating and configuring mocks](/help-center/product-documentation/creating-and-configuring-mocks).
- Open mocks from the top navigation **Mocks** entry, then choose a project from **Select a project**. Use **All Projects** to switch projects later.
- Linking mocks to endpoints (or bulk-generating them) requires a project with at least one **endpoint**; see [Endpoint management](/help-center/product-documentation/endpoint-management).

## The high-level flow

1. **Select a project** — pick a project on the **API Mocks** page to manage its mocks.
2. **Create or generate mocks** — add mocks by hand with **Create Mock**, or bulk-create them from endpoint schemas with **Generate Mock**.
3. **Start the server** — click **Start Mock Server** to serve active mocks; **Stop Server** ends it (the header shows *"Mock server running"* while active).
4. **Test and use** — try responses with a sample request, then use mocks in test execution or via the standalone server.

## Mock capabilities

| Capability | What it gives you |
|------------|-------------------|
| **Static and dynamic responses** | Fixed JSON/XML payloads, or **dynamic templates** with variables resolved at request time. |
| **Multiple responses + conditions** | One mock can hold several named responses, each guarded by conditions on the request; a **Default Response** is returned when nothing matches. |
| **Latency simulation** | Per-response **Delay (ms)** to exercise timeouts and slow paths. |
| **Standalone server** | Run mocks as a server for external testing or integrations, via a path-based or subdomain URL. |
| **Endpoint linking** | Link a mock to an existing endpoint (auto-fills path/method) or create a **standalone** mock. |
| **Protocols** | REST, SOAP (XML bodies, SOAPAction/operation matching), and GraphQL. |

## How generation works

**Generate Mock** builds example responses **from each endpoint's OpenAPI/JSON schema** (WSDL example XML for SOAP, a GraphQL data envelope for GraphQL). It is deterministic schema-to-example synthesis — no AI model is called and no provider key is needed — so it works fully offline. When a selected endpoint already has a mock, a conflict step lets you skip, update, or duplicate.

## Static vs dynamic responses

- **Static** responses return a fixed body exactly as written (JSON, or XML for SOAP).
- **Dynamic** responses use `{{ … }}` templates resolved per request:
  - Utilities: `{{uuid}}`, `{{timestamp}}`, `{{date}}`, `{{randomInt}}`, `{{randomInt(N)}}`, `{{randomFloat}}`
  - Request echoes: `{{request.query.name}}`, `{{request.headers.name}}`, `{{request.body.nested.path}}`, `{{request.path.name}}`

## Serving mocks: two URL styles

When the mock server runs, the UI offers two base URLs (with copy buttons):

- **Path-based URL** — no DNS needed; use it when the engine runs on your machine or the same server.
- **Subdomain URL** — for a centralized engine where your company has DNS. Ask your admin if unsure.

A **How to Use** panel provides ready-to-copy snippets for calling your mocks.

## When to use mocks

- The real API is **not available**, **unstable**, or **still in development**.
- You need **deterministic** negative or edge cases that are hard to reproduce live.
- You want **faster CI** or **isolated** workflows without environment flakiness.

## Best practices

- Keep mock bodies **realistic** and aligned with your contract so tests stay meaningful.
- Use **clear mock names and descriptions** so the list stays scannable.
- **Deactivate or remove** mocks when you intentionally want tests to hit the real API — only **active** mocks are served.

## Related articles

- [Creating and configuring mocks](/help-center/product-documentation/creating-and-configuring-mocks)
- [Understanding workflows](/help-center/product-documentation/understanding-workflows)
- [Endpoint management](/help-center/product-documentation/endpoint-management)