Mock data and synthetic APIs let developers build and test against a realistic API before the real endpoint exists, stabilizes, or is safe to call directly. A mock API simulates a real endpoint's responses — status codes, headers, and payload structure — so frontend and backend teams can build in parallel, and tests can hit deterministic edge cases instead of a flaky third-party sandbox. The most reliable mock APIs are backed by realistic, relational synthetic data instead of static canned responses.
What are mock data and synthetic APIs?
Mock data and synthetic APIs solve two different halves of the same problem, so it helps to separate them from the start. Mock data is the content: the values an endpoint hands back when it's called. A mock API is the interface — a simulated endpoint that mimics a real service's behavior, including its status codes, headers, and payload structure, without a request ever touching the actual backend. A client sends a request the same way it would to the real service, and the mock returns a response shaped like the one it would get back.
Teams build mock APIs three common ways. The simplest is hand-written request-and-response pairs, coded directly into a test harness or a mocking tool's configuration — fast to set up, but every new case has to be typed in by hand. The second is recorded-and-replayed traffic: capture real requests and responses from an actual integration once, then replay them later without hitting the live service again. The third is generation — building the mock's responses from a spec or from a modeled dataset rather than from examples someone wrote or recorded.
That third approach is where Tonic Fabricate fits, and it's the idea worth holding onto: a mock API is only as good as the data behind it. Hand-written stubs run out of variety fast, and recorded traffic is frozen at the moment it was captured. A mock built on realistic, relational synthetic data can return a new, internally consistent response every time it's called, and it can model relationships between resources — an order that references a real-shaped customer record — the way hand-written or recorded stubs generally can't.
How mock APIs work
A mock API's job is to stand in for a real endpoint closely enough that client code can't tell the difference. It accepts the same requests, on the same routes, with the same authentication pattern as the real service, and it returns responses that match the real API's contract — the right status codes, the right headers, the right shape of payload. From the caller's point of view, swapping a mock in for the real thing should be invisible.
Mocks run wherever the client code that calls them runs. Three places are common:
- Locally, on a developer's own machine, so a frontend engineer can build a UI against an endpoint the backend team hasn't finished yet.
- In a shared test environment, where multiple developers or automated test suites hit the same mock without racing for access to a scarce staging resource.
- Inside a CI/CD pipeline, where tests need a dependable, always-available substitute for a service that would otherwise make the pipeline flaky or slow.
In every one of those places, the mock is only as useful as the data it serves — and that pushes the question back a level: the underlying question is how that synthetic data gets generated in the first place. A mock built on thin or repetitive data will expose that thinness the moment a test asks for anything beyond the happy path.
When to use mock data and synthetic APIs
Reaching for a mock API usually comes down to one of three concrete triggers. The first is timing: the real API doesn't exist yet. Frontend and backend teams often need to work in parallel, and a mock lets the frontend team build against an agreed contract while the backend is still being written, instead of sitting idle until an integration is ready.
The second is reliability and cost. A real API might be a third-party service that's flaky in its sandbox, rate-limited, or billed per call — all reasons you don't want every test run hammering it directly. A mock removes that dependency entirely: tests run as often as needed, with no rate limit and no bill.
The third is edge-case control. Some scenarios — timeouts, malformed responses, forced failures, a payment that's declined on the third retry — are difficult or impossible to reproduce reliably against a live system. A mock API lets you define those cases directly, so a test that needs to see how the application handles a dropped connection doesn't have to wait for one to happen naturally.
These triggers show up constantly in app development, where teams need a stable target to build against while a real integration is still in flight, and they overlap closely with the broader question of how synthetic data supports software testing and QA, where deterministic, repeatable conditions matter as much as realistic data.
Traditional API mocking tools vs. synthetic-data-backed mock APIs
Tools like WireMock, Mockoon, Beeceptor, and Postman's mock servers are a mature, capable part of the API-mocking landscape, and they're good at what they're built for: fast, simple stubs that get a team unblocked in minutes. Point one at an OpenAPI spec, define a handful of example responses, and you have a working mock with almost no setup.
The limitation shows up once an application needs data that's realistic and relational rather than static. A hand-configured mock /orders endpoint can return a fixed order object all day, but the moment a test needs that order to reference a /customers record with a matching ID, a consistent order history, and realistic account details, static canned responses stop being enough. Someone has to hand-maintain the relationships between every mocked resource, and that maintenance burden grows with every new field and every new endpoint.
| Tool | How it serves data | Best for |
|---|---|---|
| Tonic Fabricate | Mock endpoints built on top of already-generated, relational synthetic data | Realistic, relationally consistent responses across multiple connected endpoints |
| WireMock | Hand-configured stub mappings, matched by request pattern | Fast, simple stubs for a small number of fixed scenarios |
| Mockoon | A desktop app for defining mock routes and static or templated responses | Quick local mocking without writing code |
| Beeceptor | Hosted mock endpoints configured through a web UI | Lightweight, shareable mocks for early-stage prototyping |
The Tonic Advantage: A Tonic Fabricate mock endpoint isn't a static response someone typed in — it's built on top of a synthetic database Fabricate has already generated. That means a mocked
/ordersendpoint can return an order that correctly references a real-shaped customer record in the same database, because the referential integrity was built into the data before the mock ever received a request.
Generating mock APIs with Tonic Fabricate
The most direct way to build a data-backed mock is to hand Tonic Fabricate an OpenAPI or Swagger spec, or describe the endpoint conversationally, and let its Data Agent build matching endpoints on top of the project's synthetic tables. Fabricate also generates an OpenAPI spec for the resulting mock API, so the mock itself is documented and shareable the same way a real service would be.
A concrete illustration makes this easier to picture. A team integrating with PayPal's checkout API needs to build and test against endpoints for orders, captures, and webhooks — but PayPal's sandbox is a well-known source of flakiness, and testing failure paths against it is awkward at best. Mocking PayPal's checkout API with Fabricate means standing up those same endpoints backed by synthetic data that mimics PayPal's production schemas, so the team can build and test the full order lifecycle — including forced failures and edge cases — without depending on PayPal's sandbox being available or predictable.
The Tonic Advantage: Because the mock and the underlying database live in the same Fabricate project, you can test the mock directly from within Fabricate before wiring a real integration to that same data. That gives a team a way to validate the mock's behavior against its own synthetic dataset before a single line of client code has to point at it — catching contract mismatches early, while the mock is still cheap to change.
Best practices for using mock APIs in development and testing
A few habits keep mock APIs useful as a project grows rather than becoming their own maintenance problem.
- Keep the mock's contract in sync with the real API as it evolves. A mock that drifts from the real service's current request and response shape stops being useful the moment client code depends on the difference — and that comes back to the underlying data's fidelity: a mock is only trustworthy if what it returns still matches what the real thing would.
- Use the mock to deliberately exercise edge cases and failure modes. Timeouts, malformed payloads, and forced failures are exactly the scenarios a mock is good at reproducing on demand, so build them in rather than hoping they show up naturally in testing.
- Never point a mock at real production data, even for "just testing." Doing so reintroduces the exact risk a mock is supposed to remove, which is really a question of keeping any re-identification risk out of your test environments altogether. Synthetic data removes that risk by design, since there's no real individual behind any record in the first place.
- Treat the cutover from mock to real API as a configuration change, not a rewrite. If client code was built against the mock's contract correctly, moving to the real service should mean swapping a base URL and a set of credentials — nothing more.
Handled this way, a mock API stops being a stopgap and becomes a permanent, reliable part of how a team develops and tests against services it doesn't fully control.