Key Concepts
Understanding these concepts will help you navigate the rest of the documentation.
Tenant
Section titled “Tenant”The boundary everything else sits inside. Your APIs, consumers, entitlements, teams and audit trail belong to your tenant, and nothing crosses that boundary except where you deliberately publish it — see API Economy.
Organisation
Section titled “Organisation”Your structure as the platform understands it: functional areas, groups and teams, with people belonging to them. This is not decoration. Governance authority is resolved through it — who must approve a change is determined by the role held for the relevant functional area and group at the moment the flow runs, so when someone moves between teams the approvals follow them without anyone editing a record.
User and Consumer
Section titled “User and Consumer”Two different populations, deliberately kept apart.
A user is a person in your organisation, authenticated through your own identity provider — Entra ID, Okta, Google Workspace or whatever you already run. Apiway does not become a second directory for your workforce.
A consumer is whoever calls your API: another team, a partner system, a customer’s application, or an AI agent. Consumers hold their own credentials and entitlements and do not exist in your corporate directory, which is where a platform’s identity model usually goes wrong — treating the two as the same thing forces you either to put customers in your staff directory or to run two disconnected worlds.
An API in Apiway is defined by an OpenAPI specification. It has a name, a technical name (used in URLs), a major version, and a lifecycle state. APIs are the central entity — everything else (deployments, subscriptions, governance) connects back to an API.
Programme
Section titled “Programme”A programme is the container for an API’s lifecycle journey. When you upload an OAS, a programme is created that tracks the API through validation, compliance, governance, deployment, and beyond. Think of it as the work order for getting an API to production.
Deployment
Section titled “Deployment”A deployment connects an API to a gateway instance in a specific environment. The deployment tells a gateway worker to generate the proxy and policy documents the gateway needs to serve traffic.
Deployments use a revision model for zero-downtime changes:
- Staging revision — The worker writes new proxy operations here
- Active revision — The gateway serves traffic from this revision
- Activate — Atomically promotes staging to active
- Discard — Rolls back staging without affecting live traffic
Subscription
Section titled “Subscription”A subscription grants a consumer access to a deployed API. Each subscription has:
- Credentials — API key or OAuth client, provisioned automatically
- Rate limits — Requests per second/minute/hour
- RU quota — Resource unit budget for metered billing
- Scopes — Which operations the subscriber can access
Gateway & Worker
Section titled “Gateway & Worker”A gateway is the runtime that receives API traffic and enforces policies (authentication, rate limiting, routing, payload protection). Apiway supports multiple gateways — Alpha, Kong, Azure APIM, Apigee, Tyk, Zuplo.
A worker is the gateway-specific translator. It takes Apiway’s deployment model and converts it into the proxy/policy documents that a specific gateway understands. Each gateway type has its own worker.
Governance
Section titled “Governance”Governance is Apiway’s workflow engine for change control. When an API is created, updated, or a subscription is requested, it can trigger an approval flow — a configurable pipeline of reviewers and conditions.
Key governance concepts:
- Template — Defines who reviews what, and in what order
- Flow — A running instance of a template, tracking approvals
- Initiator — The event that triggers a flow (e.g., new API, subscription request, budget breach)
- Outcome — Approved, Rejected, or Amendment Required
Environment
Section titled “Environment”An environment represents a deployment target — typically Development, Staging, and Production. Each environment is associated with a gateway instance and has its own endpoint URLs.
OpenSLA
Section titled “OpenSLA”OpenSLA defines the service level agreement for an API — throughput limits, RU cost rates, and tier definitions. Producers define SLA tiers; consumers select (or are recommended) a tier when subscribing.
Resource Unit (RU)
Section titled “Resource Unit (RU)”The billing unit for API consumption. Each API operation has an RU cost (configurable per operation). Subscriptions have RU quotas. The gateway meters consumption in real time and the cost centre aggregates it into P&L reports.
Entitlement
Section titled “Entitlement”An entitlement links a scope to a subscription. When a consumer’s token is issued, it carries the scopes from their entitlements. The gateway enforces these scopes per operation — no database lookup at request time.
Developer Portal
Section titled “Developer Portal”The consumer-facing view of your API catalogue. Consumers browse available APIs, read documentation, subscribe, and manage their credentials. The portal shows both APIs you produce and external APIs you consume.
API Economy
Section titled “API Economy”The marketplace layer. APIs flagged for external visibility are discoverable across tenant boundaries. When a consumer from another organisation subscribes, the OAS is copied into their tenant and goes through their own governance — maintaining full tenant isolation.