Skip to documentation

Reference · Protocols

Available

Use the protocol contract your client actually speaks

DotMock has one shared state, testing, and approval model, while matching and responses stay native to REST, SSE/WebSocket realtime, GraphQL, SOAP, gRPC, LLM APIs, and webhooks.

In this guide

  • Choose the correct workspace type
  • Understand each native matcher and response
  • Read the verified capability boundary
  • Avoid flattening specialized protocols into REST
On this page

REST

Import OpenAPI or create endpoints visually. Match method, path, query, headers, cookies, and JSON body fields; validate requests and responses; return fixed, conditional, weighted, sequence, queue, proxy, delayed, malformed, or fault behavior.

  • Dashboard authoring and runtime: Available
  • CLI and MCP: Available
  • State and response hooks: Available
  • Multipart and binary behavior is constrained by the active OpenAPI contract

Realtime SSE and WebSockets

Use OpenAPI 3.2 text/event-stream operations for SSE and AsyncAPI 3.0 channels with the WebSocket binding for connection-oriented messages. Build ordered connect/message/timer/disconnect scenarios with rooms, broadcasts, resume policy, signed browser URLs, replay seeds, proxying, and bounded timelines.

  • Dashboard contract, scenario, multi-client tester, traffic, and usage surfaces: available
  • CLI and MCP target/scenario/token/test/traffic/promotion tools: available
  • JSON and UTF-8 text are first-class; binary application messages are rejected
  • Specialized GraphQL and LLM streams remain on their native runtimes

GraphQL

Start from SDL or introspection. Match operation name and type, variables, arguments, headers, and persisted-query hashes. Return native data/errors and deterministic subscription sequences.

  • Dashboard schema and operation editor: Available
  • Queries, mutations, subscriptions, aliases, validation, and APQ: Available
  • GraphQL variables and arguments can address shared state

gRPC

Compile a multi-file .proto bundle or FileDescriptorSet into canonical descriptors. Configure descriptor-valid ProtoJSON transcripts and ordered cases for unary, server-streaming, client-streaming, and bidirectional RPCs.

  • Dashboard contract, method, tester, traffic, state, and upstream surfaces: Available
  • Native gRPC and gRPC-Web gateway: Available
  • Workspace-aware reflection v1/v1alpha and grpc.health.v1: Available
  • TLS, custom CA, mTLS proxying, decoded traffic, and explicit promotion: Available

SOAP

Import WSDL and referenced XSD sources. DotMock routes SOAP 1.1 and 1.2 by endpoint path, action, version, and body element; conditions can use XPath and return native success or fault envelopes.

  • Dashboard contract, operation, tester, traffic, state, and upstream surfaces: Available
  • SOAPAction and application/soap+xml action routing: Available
  • Native SOAP 1.1/1.2 content types and fault envelopes: Available
  • XPath conditions, XML templates, state actions, proxying, capture, and promotion: Available

LLM providers

Use specialized ordered fixtures instead of REST rules. One workspace can expose provider-shaped OpenAI, Anthropic, Azure OpenAI, Ollama, Gemini, Bedrock, and Cohere routes, including streaming and WebSocket transports where the provider contract supports them.

  • Dashboard fixture, traffic, workflow, and tester surfaces: Available
  • CLI fixture lifecycle and MCP tools: Available
  • Live provider routes: Available
  • Generic `dotmock test --kind llm`: Planned until template conformance is complete

Webhooks

A webhook workspace owns event templates, signing configuration, listeners, durable deliveries, metrics, and retries. Response Hooks connect a REST operation to an enabled event in the same team.

  • Dashboard event and delivery editor: Available
  • CLI local listeners and trigger/inspect commands: Available
  • Render and dry-run paths never send
  • Delivery failures never alter the selected REST response

What shipped workspaces share

REST, realtime, GraphQL, SOAP, gRPC, LLM API, and webhook workspaces use team isolation, revisioned definitions, validation, deterministic simulation, API-scoped or workspace-shared state definitions, audit records, and explicit destructive approval boundaries.