Mock API testing for AI coding agents

Build against a hosted mock REST API with realistic data, stateful CRUD, delays and failures. Let your coding agent inspect calls and test recovery over MCP.

The SDK examples use an authenticated SocketHelp client. Set up the SDK or connect your agent over MCP.

Build before the upstream API is ready

A missing API key, unfinished backend or unreliable staging service should not stop a coding agent from building a client. A mock API makes the response contract explicit: the method, path, status, content type, headers and body are the test fixture.

Start with the smallest response your client actually consumes. Add a missing-field response, an empty result and a failure path before adding more sample data. These scenarios expose assumptions that a large success-only fixture can hide. A mock passing your tests does not prove compatibility with the real upstream API.

Define routes and inspect the calls

Call create_mock_api through MCP, or createMock in the TypeScript SDK. Private access is the default; provide the separate caller token to the application under test. Management access controls configuration and call inspection, not permission to use an unrelated private endpoint.

Routes support templated request values and fake-data placeholders. Configure response delays and failure behavior to exercise retry and timeout handling. Inspect recent calls to check the method and path your client actually sent, then export the fixture into your own test suite when repeatability matters.

Create a small private fixture

const mock = await socket.createMock({
  name: 'Users fixture',
  routes: [{ method: 'GET', path: '/users/42', status: 200,
    contentType: 'application/json', body: '{"id":42,"name":"Ada"}' }],
});
const response = await socket.request('GET',
  '/mock/' + mock.id + '/users/42', undefined, mock.accessToken);
console.log(response);
await socket.remove('mocks', mock.id);

Test writes as well as reads

For a client that creates or edits records, use a stateful CRUD collection rather than a static success response. Seed the collection, create a record, update it and read it back. Resetting restores the seed so the next scenario starts from known data.

The collection has bounded record and storage limits and supports revision guards to detect conflicting writes. Keep fixtures small. Proxy-and-record against a public upstream is a separate paid feature; mocks do not execute arbitrary user code and are not a replacement for a production database.

Mock a tool server when the agent is the client

A mock MCP server is useful when you need to test tool discovery, argument validation, configured errors or latency. It returns the responses you define rather than calling a real model or running tool code. This is different from the socket.help platform MCP connection that manages resources.

Create separate fixtures for success, denial and malformed upstream data. Keep tokens out of source control and delete temporary resources after the test. Use a real integration environment for the final compatibility check.