Mock Data

An API deployed from its specification answers immediately, with responses generated from the contract. That is enough to prove a shape. It is not enough to prove a product.

Why

A generated mock forgets. A consumer posts a record, gets a plausible response, asks for the record back — and it is not there, because nothing was ever kept. Every demo is one request long.

That is the difference between showing an endpoint and running a proof of concept. Evaluators want to create something, find it again tomorrow, change it, list what they have created, and hand the whole thing to a colleague who sees the same data. None of that needs your implementation to exist. It needs the mock to remember.

What you get

Switch an API’s mock to dynamic and its collection and item paths start behaving like the real thing, per tenant:

Action	What happens
POST to a collection	The document is stored and returned with a Location header pointing at its own path
GET on that path	The stored document comes back — the id the consumer was given resolves
GET on the collection	Lists what has been stored, honouring the skip and take your contract declares, with count reporting the total before paging
PUT on an item	Replaces the document and keeps its id
DELETE on an item	Removes it — and GET, PUT and DELETE on that id return 404 afterwards
An id nobody stored	404, because in dynamic mode the store is what exists

Everything else still answers from the contract. The data is the consumer’s own: Apiway does not validate, enrich or interpret it, and each of your environments keeps its own, so a demo in test cannot be seen from production.

Each partner sees only their own

Every consumer is its own tenant, and by default what a consumer stores is kept for that tenant alone. If two partners integrate against your API, each works with their own records: partner A cannot list, fetch or change anything partner B created, and neither can see each other’s identifiers. People within one partner’s organisation share that partner’s data, so their developers and testers see the same thing.

That is the same isolation your real service will enforce, so partners are not building against a shared sandbox that behaves differently from production.

The exception is an API whose data is open — the same for every consumer, such as a public catalogue or reference data. There, every consumer works with the same records: what one creates, the others can see. Again, that matches how the API will behave once your service answers.

Stored documents expire automatically after the retention period — 90 days by default — so a proof of concept can run for months without anyone tidying up afterwards, and nothing lives forever.

Note

An API whose mode has never been set is static: every response is generated from the OAS and nothing is stored or read. Existing mocks do not change behaviour until you switch them.

Where the values come from

Before anything is stored, a response has to be invented, and what a partner sees depends on what your contract says — in this order:

1. Your examples. If a field or schema carries example or examples, that is what comes back. This is the lever: a contract with examples produces a stand-in that reads like your product, with your identifiers, your wording, your realistic amounts.
2. Your enums. A field with allowed values returns one of them, so a partner never sees a status your service would never send.
3. Its format. Failing the above, the value is generated to match — a real UUID for uuid, an ISO timestamp for date-time, user417@example.com for email, a plausible phone number, a valid-looking IPv4, base64 for binary, and masked characters for a password. Types missing from the contract are inferred from the format where possible.

So the answer to “will it look like my API or will it say string” is that it looks like whatever you described. Writing examples into the contract is the highest-value hour you can spend before handing it to a partner, and it pays twice: the same examples are what your documentation shows.

Where several examples exist, one is chosen for each request, so repeated calls vary rather than returning a fixture. If a partner needs a specific value to be stable, create it — anything stored comes back exactly as it went in.

How you plug in

Choose the mode for an API:

PUT https://mock.api.apiway.net/v1/apis/{apiId}/mockData
{ "dataType": "dynamic" }

The tenant comes from your token. Set it back to static at any time to return to generated responses.

When a demonstration is over, or an evaluation starts again from nothing:

DELETE https://mock.api.apiway.net/v1/apis/{apiId}/mockData

That purges every document stored through this API’s mock for your tenant, across every major version. The mode is left as it is, and the API answers from an empty store. It is a reset rather than a delete of any one record — the record-level delete is the one your consumers already make against the API itself.

What it costs

Calls to a stand-in are metered like any other traffic: they consume Resource Usage, which draws down your credit balance at a fraction of a unit per call, with no separate charge for the environment they run in. Storing and reading documents in dynamic mode is part of serving the request rather than an extra.

That is deliberately the cheap part. Your balance mostly goes on what the platform does — designing, publishing, comparing specifications, compliance and impact analysis — not on answering requests. A partner hammering a stand-in for a fortnight is not what moves it. See Credits and Resource Usage.

Where it fits

This is step two of product delivery: the API is live and integrable before an implementation exists. Deploy it with Quick Deploy, switch the mock to dynamic, and consumers can build against something that behaves like your product while you build the product.

When the real service is ready, release it to the upstream target. Nothing your consumers integrated against changes.