Create realistic API simulations by maintaining state across multiple requests. Build mocks that feel like a real backend.
Most mock servers only return static data. Stateful mocking allows your mock API to remember what happened in previous requests. If you POST a new user, you can GET that user back later.
Data survives between calls
Modify state via requests
Dynamic conditional logic
Start by defining the initial state for your project. This is where you describe your resources (users, posts, products) and their starting data.
In your endpoint response customization, use the statehelper to read and write to your project data.
Configure your GET endpoints to return data directly from the current state.
Model login/logout by updating an isAuthenticatedflag in state and checking it in protected routes.
Simulate adding, removing, and updating items in a cart that persists while the user explores your frontend.
Build realistic CRUD (Create, Read, Update, Delete) apps without needing a real database or backend team.
Track user progress through complex onboarding or checkout flows by storing step data in the mock state.
In production, state is stored in Postgres (STATE_STORE_BACKEND=postgres). Data persists across restarts and horizontal instances.
API: GET/PUT/DELETE /api/projects/{id}/state
Things can get messy when testing. You can reset your project state at any time via:
X-Mock-Reset: true header in any request