What Apiway Governs

One sentence: the contract and the promise are governed; the implementation is yours.

That boundary is worth being precise about, because most of the disappointment with API platforms comes from it being left vague until something crosses it.

What stays yours

The API implementation. Your language, your framework, your code.
The infrastructure it runs on. Where and how it is hosted is your decision.
The data. Apiway does not store your domain data or sit in its path. The one exception is opt-in: an API whose mock is switched to dynamic keeps what consumers send it, so a proof of concept behaves like the real thing before an implementation exists. It is deleted after the retention period (90 days by default), and resetting the mock purges it at once.
Business logic, including validation, enrichment and anything else the capability does.
Transformation into another system’s format.

None of these are things the platform improves by taking over. They are where your knowledge of the domain lives.

What Apiway governs

The contract. The design standard applied when it is written, and the specification as the artifact that produces the running surface rather than describing it afterwards.
Who may reach it. Consumers, subscriptions, and the identities and roles behind them.
What they are entitled to. Per-operation scopes, enforced at the gateway rather than trusted to each implementation.
What happens when it changes. Which consumers are affected, and whether a release breaks a promise already made to them.
The evidence. Who may reach what, under which entitlement, and who approved it.

Transformation is not the platform’s job

The most common request that crosses the boundary is mediation: “can the platform convert our data into the format this other system expects?”

It can be made to. It shouldn’t be.

Consider a system that masters organisational data, with two consumers — one that reads organisational units, and one that must be updated in a different, externally defined standard. The tempting shortcut is to publish the data already shaped for the second consumer, or to have the platform transform it in flight.

Both make the same mistake. The contract stops describing the capability and starts describing one consumer’s requirements. The next consumer then receives a payload shaped by a system it has nothing to do with, and every subsequent addition becomes a coordination exercise between parties who should never have needed to speak.

The producer publishes the capability in its own domain terms. Anything that needs it in a different shape does that mapping on its own side, as a consumer like any other. The mapping is application logic, and it belongs with whoever needs the mapping.

Why the boundary is worth defending

A platform that transforms becomes an integration bus. Integrations do not accumulate — each new one costs what the last one did — so the economics that made the API approach worth adopting quietly disappear, even though every individual deliverable looks correct.

Holding the line keeps the contract as the unit of value, which is the only thing that makes the fifth consumer cheaper than the first.

What this means in practice

When something does not work, the boundary tells you where to look. A failing transformation is yours. A consumer reaching an operation they should not is the platform’s. A contract that changed without its consumers being told is the platform’s. A capability behaving incorrectly is yours.

That division is also why leaving costs what it costs: the part with your domain knowledge in it was never held here. See Access Evidence for what the platform can show about who reaches what — and why the same resources answer both an access review and a question about portability.