Binary WebSocket payloads
LimitedBinary application messages are rejected with WebSocket close code 1003.
DotMock documentation
AvailableBuild the behavior your client actually needs.
Start with a real protocol contract. Add matching, state, sequencing, failures, or delivery. Prove the result safely, then call the published runtime from your application.
Published runtime request
Call the configured mock
curl "$MOCK_URL/users/usr_123" \
-H 'accept: application/json'Expected result: the status, headers, and JSON body configured for the matching user scenario.
Start by task
One useful path at a time.
Each route below ends in observable behavior rather than a feature tour.
- 01Build the first mockCreate a REST workspace, store one resource, and prove both the success and missing-data branches.Open the quickstart
- 02Choose a native protocolStart from the contract your client speaks: OpenAPI, AsyncAPI, GraphQL SDL, protobuf, WSDL, or a provider-shaped LLM route.Compare protocols
- 03Add state, failures, or sequencingMove beyond static stubs with persistent data, ordered conditions, deterministic timelines, and explicit transport faults.Model behavior
- 04Connect the CLI or an agentInspect and author the same workspaces from a repository, CI job, or approval-aware MCP client.Automate a workflow
- 05Check the boundary before you depend on itUse the verified matrix for shipped behavior, constrained paths, and work that remains planned.Read the capability matrix
Runtime model
Request → match → state → response
RequestMethod, path, headers, body
MatchOperation, ordered condition
StateRead, mutate, or leave unchanged
ResponseTyped template, fault, or stream
Native protocols
Keep the contract your client speaks.
REST
OpenAPI, matching, typed templates, state, faults, proxying, hooks
Open guideRealtime
SSE and UTF-8 WebSockets, scenarios, replay, traffic, proxying
Open guideGraphQL
SDL, queries, mutations, variables, errors, subscriptions, APQ
Open guideSOAP
WSDL and XSD, SOAP 1.1/1.2, XPath, faults, state, proxying
Open guidegRPC
Protobuf, four RPC modes, reflection, health, state, traffic, mTLS
Open guideLLM APIs
Provider routes, ordered fixtures, tool calls, structured output, streams
Open guideWebhooks
Templates, signing, delivery, listeners, retry, response hooks
Open guideBehavior
Static examples are the starting point.
State
Persist maps, counters, queues, collections, sessions, TTLs, snapshots, and state machines.
Read the guideFailure
Keep application errors, latency, malformed output, disconnects, and upstream failures explicit.
Read the guideSequencing
Use ordered branches, fixtures, or event timelines to make repeated calls deterministic.
Read the guideProof
Dry-run the real matcher and renderer in an isolated state overlay before a live request.
Read the guideOperate from a repository or CI.
The CLI covers discovery, creation, endpoint behavior, definitions, state, protocol workflows, traffic, and delivery.
CLI guideGive an agent scoped tools.
MCP tools inspect real workspace evidence, mutate drafts, simulate behavior, and keep destructive or secret-bearing actions bounded.
MCP guideVerified July 24, 2026
Capability matrix and boundaries
Status comes from the current backend capability policy, protocol runtimes, CLI command definitions, MCP registry, and connected UI surfaces.
Implemented paths
11 capability groups verified
- REST runtime
- Realtime text and JSON
- GraphQL
- gRPC
- SOAP
- Webhook delivery
- State management and snapshots
- Publication and rollback
- CLI
- MCP
- LLM fixtures, provider routes, and streaming
Explicit boundaries
Constrained or gated paths stay separate from shipped behavior.
Generic CLI LLM dry-run
PlannedThe backend adapter remains gated until template conformance is complete.
“Available” means the described path is implemented on the cited current surfaces. It is not a promise that every protocol feature or third-party variation is supported.