Into Your Own Systems

Most platforms answer “does it work with what we already have?” with a list of connectors. You look for yours, and either it is there or you wait. The list is the product roadmap, and the things on it are the only places your data can go.

Apiway is built the other way round. Everything it knows is a resource with a published contract, callable with the credentials you already have. So the question is not whether a connector exists — it is where you want the data to go.

Taking the payment is the easy part

Charging a card is a solved problem and you can add it in an afternoon. The hard part is knowing what to charge: which customer used which API, under which plan, at which rate, and being able to show the working when they query the bill. That is the part Apiway already did, from the moment your product went live.

Apiway is API first, so billing is an API rather than a second invoicing screen — deliberately. Your finance system is the one your accountants, your auditors and your tax authority recognise, and a second system of record for money helps nobody. Because Apiway is API first, Stripe, any other payment provider, or the finance system that raises your invoices today reads the line items straight from Apiway’s API — nothing has to be re-keyed or reconciled.

What you can take, and where it comes from

What you want	Where it comes from
Consumption as line items — which API, which customer, what it was worth, when	GET /v1 (resource units)
The same consumption totalled, for a dashboard	GET /v1/summaries
Security and refusal events, as they happen	GET /v1/events/subscribe (server-sent events)
A risk position you can put on a dashboard	GET /v1/risks
Drift, upstream health, credential and version events, to a URL of yours	POST /v1/eventsubscriptions (signed webhook)
Who your consumers are	GET /v1/consumers
Who is subscribed to what, and what each may call	GET /v1/subscriptions, GET /v1/subscriptions/{id}/operations
Who approved an access, and when	GET /v1/subscriptions/{id}/approvalFlows/{flowId}/approvals
Every specification as published	GET /v1/openapispecs/{id}/content
The service levels in force	GET /v1/openslaspecs/{id}/content
The architecture decisions and principles applied as you built	GET /v1/adrs, GET /v1/principles

Three shapes people use

Usage into invoicing. Read the consumption for the period, map each customer to their record in your finance system, and raise the invoice there. Your existing dunning, tax handling, credit notes and revenue recognition continue to apply, because you never left them.

Because consumption is recorded per API and per customer rather than as a single number, the invoice can be itemised — a line per product, per API, per environment, with the value already calculated from the plan that customer is on. A customer who queries their bill gets an answer instead of an apology.

A statement assembled from it reads like this, with figures for illustration:

Acme Logistics — Standard tier
Service levels: 200,000 RU / month, 100 req/min sustained

March 2026          consumed  143,820 RU

  Payments API                61,400
  Shipment Tracking API       38,250
  Rates API                   21,900
  Address Validation API      14,180
  Webhooks API                 8,090

Every figure there comes from the resources above: the tier and its limits from the customer’s subscription, the total and the per-API breakdown from their consumption over the period. Nothing is reconstructed and nothing is estimated.

Events into monitoring. Subscribe to the event stream and forward it into whatever you already collect into. Refusals arrive attributed to a named consumer rather than an address, so they join the rest of your security signal instead of forming a separate island.

Events to your on-call

Register a URL with POST /v1/eventsubscriptions and Apiway delivers events to it as they happen — into whatever already wakes someone up. Each delivery is signed with a secret only you and Apiway hold, so the receiver can verify where it came from, and a delivery that fails is retried.

Event	Why you would want it on-call
DesignDrift	What is running no longer matches the contract your customers built against
UpstreamHealthIssue	Your service behind the gateway is struggling
CredentialExpiringSoon, CredentialRevoked	A customer is about to lose access, or just did
VersionDeprecated, VersionSunset	Customers still on a version that is going away
SubscriptionWaitlistedForCapacity, TierChangeRequested, SlaChanged	Demand is outgrowing what you promised

Security and refusal events — 401s, 403s, protection violations, rate-limit breaches — come through the live stream at GET /v1/events/subscribe and the position at GET /v1/risks; see Risk Management.

The record into your own store. Specifications, subscriptions, entitlements, approvals and service levels are ordinary reads. Snapshot them on whatever schedule suits you and keep a copy of your governed history wherever you keep the rest of it.

Nothing here is privileged

The command line tool is a consumer of these same resources, and so is the app, and so is any agent reaching Apiway over MCP. None of them has access you do not, and none of them uses an interface that is closed to you. Whatever the tooling can do, a script of yours can do with the same credentials — which is why there is no category of thing that is only available “through the product”.

What this means for leaving

The same property is why there is nothing to negotiate about getting your data back. See Exit and Continuous Audit — checking us and leaving us are the same piece of work.

See also: CLI & MCP · Metering · Risk Management