The website is written for everyone who has a say in choosing Apiway, so it describes outcomes: who
gets in, what they may do, the service you promise. If you evaluate technology, this page is the
translation — each outcome, the standard or component it rests on, and where to read about it.
Apiway is a product delivery platform. The components below are parts of it, the way an engine
is part of a car: each is familiar on its own, and what Apiway sells is that they arrive already
working together, driven from one contract.
| On the website | Technically | Read more |
|---|
| Who gets in, and what they may do | An OAuth 2.0 / OpenID Connect authorisation server issuing every token — client credentials, and authorisation code with PKCE | Authentication, Standards & Conformance |
| Identity Guard | The authorisation server plus per-request authorisation at the gateway | Identity Guard |
| Each customer gets their own credentials | A client per subscription, scoped to what the customer’s plan entitles | Scopes & Entitlements |
| Your people sign in with what they already use | Federation with any OIDC identity provider — Entra, Okta, Auth0, Google | Identity Providers |
| When someone leaves | Authorisation resolved live on every request; why there is no SCIM directory synchronisation | When Someone Leaves |
| Access withdrawn on the next call | Per-request entitlement resolution; RFC 7009 token revocation; JWKS key rotation | Revocation & Token Lifetime |
| What reaches your backend | A verified token carrying the customer (tenant claim), the client (sub) and its scopes; UserInfo for a person’s profile | What Reaches Your Backend |
| On the website | Technically | Read more |
|---|
| The front door your customers call | An API gateway — Apiway’s own, or the one you run (Kong, Azure API Management, Apigee, Tyk, Zuplo) | Multiple Gateways, Deployment Models |
| From idea to live product | OpenAPI contract design, a stateful mock at the final address, then your implementation behind it | Design Studio, Mock Data, Going Live |
| Changes that never break customers | Semantic versioning enforced at the gateway: a breaking change cannot go onto a version in use | Versioning |
| Proof it runs as designed | Contract verification: tests generated from the OpenAPI document run against every deployment, and continuous drift analysis of what runs against what was specified | Assurance, Compliance |
| Nothing ships that breaks a customer | Approval flows with governance templates | Approval Flows |
| On the website | Technically | Read more |
|---|
| The service you promise, enforced | OpenSLA documents: tiers, rate limits, quotas, a protective ceiling; 429 / 402 at the edge | OpenSLA |
| Early Warning | Risk events classified and pushed live (server-sent events), plus signed webhooks for drift, upstream health and capacity | Risk Management, Into Your Own Systems |
| Who is affected | Dependency and consumer analysis before a change | Blast Radius |
| Wealth Engine | Metering in resource units per customer and operation, credits, and line items by API | Metering, Credits, Wealth Engine |
| Everything you sell and buy | The API economy: APIs you produce and APIs you consume, under the same rules | API Economy, External APIs |
| Your shop window | A developer portal and marketplace with self-service subscription | Marketplace, Subscribing |
| On the website | Technically | Read more |
|---|
| Compliance evidence, produced as you run | Grants, approvals and refusals recorded by the same system that enforces them | Access Evidence |
| Yours to leave | Every record is an API read you can take with you | Exit & Continuous Audit |
