User GuidesAPI Mocking

API Mocking

API mocking is serving stand-in responses for an API so clients can be developed and tested before the real backend is ready. A²D takes a design-first approach: you design the REST API or MCP server specification first, and the mock responses are generated from that contract — so the mock never drifts from the API it represents. It supports multiple scenarios, authentication types, and environments out of the box.

A²D mocks both classic REST APIs and MCP servers from the same design-first workflow. For the MCP-specific view, see MCP mocking.

Why design-first API mocking

Traditional mocking tools ask you to hand-write mock responses that quickly fall out of sync with the real contract. Design-first flips that:

  • The contract is the source of truth — mocks derive from the spec.
  • No drift — change the design, the mock updates with it.
  • Shift-left quality — validate and test against the mock before any backend code.
  • Shared understanding — consumers and producers agree on the contract early.

Scenarios, auth, and environments

A useful API mock covers more than the happy path:

  • Multiple scenarios per operation — success, empty, partial, and error responses.
  • Authentication types — mock the auth flow clients will actually use.
  • Environments — Mock, Pre-prod, and Prod per asset, switched without client changes.
GET /v1/orders/ORD-1001
Authorization: Bearer <token>
 
200 OK
{
  "id": "ORD-1001",
  "status": "shipped",
  "items": [{ "sku": "A-42", "qty": 2 }],
  "total": 129.5
}

From mock to tests

Because the mock is contract-accurate, the same design drives your tests:

  • Build test suites that call the mock and assert on responses.
  • Run suites across environments and track coverage.
  • Promote from Mock to Pre-prod to Prod as the real backend comes online.

See Testing REST API endpoints and the testing framework.

Next Steps

Mock from the contract, not around it — design-first API mocking that never drifts. 🎯

MCP MockingMock AI Agents