Skip to content

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 wantResource
Every API you have published, and its versionsGET /v1/apis, GET /v1/apis/{id}/versions
The OpenAPI specification of each, as publishedGET /v1/openapispecs, GET /v1/openapispecs/{id}/content
The service levels attached to each versionGET /v1/openslaspecs, GET /v1/openslaspecs/{id}/content
Every approval flow, who approved, and whenGET /v1/apis/{id}/approvalFlows, GET /v1/apis/{id}/approvalFlows/{flowId}/approvals
The same flows as a diagram, if a report needs oneGET /v1/apis/{id}/approvalFlows/{flowId}/svg
Every deployment, and the environment it went toGET /v1/deployments
Who your consumers areGET /v1/consumers
What each subscription was granted, per operationGET /v1/subscriptions, GET /v1/subscriptions/{id}/scopes, GET /v1/subscriptions/{id}/operations
The approvals behind each subscriptionGET /v1/subscriptions/{id}/approvalFlows
How data in each API is classifiedGET /v1/dataclassifications
What was verified, and what it returnedGET /v1/verifications, GET /v1/verifications/{id}/cases
The architecture decisions and principles applied as you builtGET /v1/adrs, GET /v1/principles
The governed context as one projectionGET /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.

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.

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