DotMock

Build your first mock

Start in your terminal.

One command installs the CLI and connects it to this browser.

01  Install02  Authenticate

Install and connect

Run this in a terminal. The modal will continue as soon as the CLI checks in.

Creating a secure setup session…

The CLI stores a team-scoped key in ~/.dotmock/config.json. Never commit that file.

How DotMock works

Put unstable dependencies inside a controlled loop.

DotMock does not replace your backend. It gives the backend and its agents a stable environment for integrating, failing, retrying, recovering, and proving what happened.

01

Create or import the contract

Start from OpenAPI, GraphQL, WSDL, Protobuf, or a focused workspace. DotMock keeps protocol-specific structure instead of flattening everything into generic HTTP.

02

Model behavior, not only responses

Add conditions, persistent state, latency, failures, streams, tool calls, and outbound events so the dependency behaves like the system your code must survive.

03

Point the development environment at DotMock

Swap the third-party base URL or client target in development and test configuration. Keep the application flow and client code intact.

04

Exercise, inspect, and reset

Run the real flow, inspect matched traffic and state changes, verify deliveries, then reset the environment for a reproducible next run.

Governed agent execution

Agents move faster when the environment has boundaries.

CLI and MCP access use the same evidence-first sequence. Costly or sensitive changes remain visible and approval-gated.

  1. 01

    Inspect

    Read the active contract, state, traffic, and capability boundaries before changing anything.

  2. 02

    Draft

    Prepare the smallest workspace change without publishing it immediately.

  3. 03

    Validate

    Run validation, simulation, or a dry run and show the expected response and state diff.

  4. 04

    Approve

    Require explicit approval for publication, rollback, deletion, reset, or other sensitive actions.

  5. 05

    Verify

    Report the resulting route, revision, traffic, delivery, or state evidence.

What teams run

Rehearse the difficult path before it becomes an incident.

Recover from an upstream outage

Stage latency, timeouts, retries, and a controlled recovery without waiting for the real provider to fail.

Complete a stateful checkout

Move a cart through payment and fulfillment state while emitting the same webhooks the backend consumes.

Test an LLM tool loop

Return a deterministic tool call, accept the tool result, then stream the final provider-shaped response.

Prove authentication failures

Exercise expired credentials, missing scopes, rate limits, and recovery paths against a stable contract.

Start with one dependency

Make the whole development loop reproducible.

Read the docs