Exit and Continuous Audit
Most platforms answer the portability question with an export feature. Somebody builds a job that assembles a bundle, and from then on every conversation about leaving is a conversation about that bundle — what it contains, how current it is, what was left out, whether it still works.
There is no bundle here, and that is the stronger position rather than a gap.
Everything the platform governs is already an API. The specification of every API you have published, every version and what changed between them, every approval and who gave it, every subscription and what it was granted, the architecture decisions and principles the platform applied as you built — each is a resource you can call today, tomorrow, and on the morning you decide to leave. Exit is not an event. It is the same operation as an audit, continued.
What you can take, and where it comes from
Section titled “What you can take, and where it comes from”| What you want | Resource |
|---|---|
| Every API you have published, and its versions | GET /v1/apis, GET /v1/apis/{id}/versions |
| The OpenAPI specification of each, as published | GET /v1/openapispecs, GET /v1/openapispecs/{id}/content |
| The service levels attached to each version | GET /v1/openslaspecs, GET /v1/openslaspecs/{id}/content |
| Every approval flow, who approved, and when | GET /v1/apis/{id}/approvalFlows, GET /v1/apis/{id}/approvalFlows/{flowId}/approvals |
| The same flows as a diagram, if a report needs one | GET /v1/apis/{id}/approvalFlows/{flowId}/svg |
| Every deployment, and the environment it went to | GET /v1/deployments |
| Who your consumers are | GET /v1/consumers |
| What each subscription was granted, per operation | GET /v1/subscriptions, GET /v1/subscriptions/{id}/scopes, GET /v1/subscriptions/{id}/operations |
| The approvals behind each subscription | GET /v1/subscriptions/{id}/approvalFlows |
| How data in each API is classified | GET /v1/dataclassifications |
| What was verified, and what it returned | GET /v1/verifications, GET /v1/verifications/{id}/cases |
| The architecture decisions and principles applied as you built | GET /v1/adrs, GET /v1/principles |
| The governed context as one projection | GET /v1/governance |
These are the same resources the platform runs on. There is no separate reporting copy that could drift from them, and no export path that could be maintained less carefully than the runtime one.
Keeping your own copy
Section titled “Keeping your own copy”If you want the record on your own side, call the resources on whatever schedule suits you and store what comes back. Nightly, quarterly, or once because an auditor asked — it is the same call either way, with the same credentials you already use.
Nothing has to be requested, no notice period applies, and there is no export feature that could be deprecated out from under you. A team that has been snapshotting monthly since the day they signed up already holds their exit, and never had to think about it as one.
What you would actually lose
Section titled “What you would actually lose”Being straight about this matters more than the reassurance.
The artefacts are yours and they are portable: specifications are OpenAPI, service levels are OpenSLA, and both are open formats that other tooling reads. Credentials issued through Apiway are data you can export, and re-issuing credentials is something you would do moving between any two providers.
What does not come with you is the orchestration. Today one question — who approved this, against which decision, under what service level, reaching which consumers — is a query. Afterwards those answers live in whatever systems you moved them to, and correlating them is work somebody does by hand again. That is a real cost, and it is the only one specific to Apiway. It is not a lock: it is what you were buying.
See also: Access Evidence · Assurance · Compliance & Drift