How to use this API management requirements checklist
Before you choose a gateway, a control plane or a partner, you need a written statement of what the API management layer must do for your organization. The checklist on this page answers that question by listing the requirements that an open-source gateway such as Apache APISIX or Kong Gateway has to meet, and by showing where each requirement is met by the gateway itself, by an identity provider, by the application behind it, or by your operating processes. Requirements are grouped into functional, security, integration, operational and compliance categories. Functional items cover the APIs in scope, traffic volumes, routing, versioning and the developer portal. Security items cover authentication with OIDC, keys and mutual TLS, rate limits and the protection of sensitive data in transit. Integration items cover identity providers, observability pipelines and partner onboarding. Operational items cover deployment mode, control plane location, upgrades and the API inventory. Compliance items cover the sector standards and evidence your auditors will ask for.
Use the verification column to turn each requirement into a test you can run during evaluation, not a claim a vendor makes in a slide deck. For each row, record who verified it, in which environment, and what evidence was produced, such as a configuration file in Git, a test result or a log sample. Before any vendor conversation, ask each business owner (for example, the head of the partner program, the payments lead, the data protection officer and the platform team) to rank the requirements in their area as must have, should have or later. Rankings from business owners usually differ from the ranking an engineering team would produce, and the differences are where most scope disputes start. Ask for these rankings in writing and keep them with the checklist. DeployOpen implements, hardens and supports self-hosted platforms like these, and runs security testing against them, but it does not issue audit reports, attestations or certifications. The compliance rows show what evidence to prepare for an independent assessor, not a certificate that the gateway is compliant.
Functional requirements: APIs, traffic, rate limits and inventory
This table lists the functional requirements that size an API gateway deployment and shape its configuration, with the evidence to collect for each. Use it to turn business needs into written acceptance criteria before comparing Apache APISIX, Kong Gateway or a partner-run service. Items marked as items to confirm depend on plugin coverage or portal features that you should test yourself.
| Requirement | Why it matters | How to verify |
|---|---|---|
| API and endpoint inventory | Gateway sizing, route counts and migration effort all depend on how many APIs exist and who owns them. | Export route and service lists from existing gateways, load balancers and code repositories, then reconcile them against an owner register. |
| Traffic volume and peak requests per second | Peak load, not average load, drives node count, etcd or database sizing and failover design. | Pull 12 months of access logs or metrics per API, identify peaks, and load test the target topology at a multiple of observed peak. |
| Protocol support (HTTP/3, gRPC, WebSocket, TCP/UDP) | Each protocol changes which listeners, certificates and plugins are needed, and some plugins only apply to HTTP traffic. | List every protocol in use. APISIX documents HTTP/HTTPS, HTTP/3 with QUIC, gRPC, WebSocket, MQTT, Dubbo and TCP/UDP proxying; confirm each one in a proof of concept. |
| Rate limits per consumer and tier | Limits protect back ends and enforce partner or plan contracts, so they must be keyed to a consumer identity, not only an IP address. | Write the limit matrix (consumer, tier, window, burst). Test that a limit for one consumer does not affect another and that responses carry the expected status codes. |
| Developer portal and partner onboarding | Partners need credentials, documentation and sandbox access without manual tickets. Open-source gateways do not all include a portal, so the path must be defined. | Confirm with the vendor whether the chosen edition includes a portal, Kong Manager or a separate developer portal. Run one partner onboarding end to end in a test environment. |
| API versioning and lifecycle | Consumers break when versions change without notice, and retired versions often stay exposed. | Document the versioning scheme, deprecation notice period and retirement steps. Check that routes for retired versions return a defined response after removal. |
| Plugin and custom logic coverage | Requirements that depend on a plugin not in the edition you choose become custom code to build and maintain. | Map each requirement to a named plugin. APISIX lists more than 100 built-in plugins; Kong's OpenID Connect plugin is Enterprise tier. Confirm coverage for each item in writing. |
| Configuration and release control | Gateway configuration changes often, so unmanaged edits create outages and audit gaps. | Specify how routes and plugins are stored, reviewed and promoted between environments, and test a rollback of a faulty route change. |
Which authentication model fits each consumer type
Internal staff and single-page applications usually authenticate a person, so the gateway should validate tokens issued by your identity provider rather than store credentials of its own. The APISIX openid-connect plugin supports authorization code, client credentials, token introspection and PKCE flows, which covers browser-based apps and back-end services that call APIs on a user's behalf. Confirm the exact flow combination against your identity provider, because each provider handles refresh tokens, audience claims and PKCE settings differently.
- Authorization code with PKCE: the usual pattern for SPAs and native clients, where no client secret is embedded in the browser.
- Token introspection: lets the gateway ask the identity provider whether an opaque token is still active, at the cost of a network call per check unless results are cached.
- Token validation at the edge: signed JWTs can be verified locally against the provider's published keys, which keeps latency low but delays revocation until token expiry.
- Audience and scope checks: confirm that tokens carry the expected audience so a token issued for one API cannot be replayed against another.
- Session handling: decide where refresh happens and how logout propagates to the gateway.
Check with your identity team which providers you run (for example, Keycloak, Microsoft Entra ID or Okta), which flows each one enables for your clients, and how token lifetimes are set.
Partner systems, scheduled jobs and integration platforms usually have no user in the loop, so they fit the client credentials grant or API keys. Client credentials issues short-lived access tokens to a registered client, which lets you rotate and revoke a partner's access centrally. API keys are simpler to issue but carry more risk, because a leaked key is valid until someone revokes it, so they work best with tight scopes, per-consumer rate limits and a clear rotation process.
- Client credentials: the preferred choice for machine clients when your identity provider can issue tokens per partner with defined scopes.
- API keys: acceptable for lower-risk integrations, with keys stored hashed or in a secret manager and rotated on a schedule you set.
- Per-consumer rate limits: attach limits to the client or key identity so one partner cannot exhaust shared capacity.
- Scope mapping: tie each partner to the routes and operations it needs, nothing more.
- Revocation path: confirm how quickly a compromised key or client can be disabled across all gateway nodes.
Confirm with your identity provider and gateway team how client credentials are provisioned, how long tokens live, and whether key rotation can be automated without partner downtime.
Partners exchanging regulated or high-value data often need mutual TLS, where both the client and the gateway present certificates. Mutual TLS binds the connection to a specific client certificate, so possession of a bearer token alone is not enough. It is often combined with OAuth tokens so the gateway checks both the transport identity and the authorization context. Sector standards such as FAPI 2.0 describe this pattern for financial services, and the sibling topics cover those requirements in detail.
- Certificate issuance: decide whether your private certificate authority or the partner's issues client certificates, and who owns renewal.
- Certificate-to-client mapping: the gateway must tie a certificate to a consumer identity, which requires a documented mapping for each partner.
- Revocation checking: confirm how revoked or expired certificates are detected and whether revocation lists or short lifetimes are used.
- Combined token and certificate checks: verify the gateway can require both where your standard calls for it.
- Operational ownership: partner certificate rotation generates support tickets, so assign a named owner on each side.
Confirm with your gateway team which mTLS and certificate-binding options the APISIX or Kong edition you select supports, since plugin tiers and features differ between open source and enterprise builds.
Security requirements the gateway must meet
A gateway sits on the boundary between clients, partners and your internal services, so its security depends on how it is exposed, who can change it and what it logs. The cards below cover the controls to specify before selecting between Apache APISIX and Kong, and the point where enforcement stops and application code must take over.
TLS termination and mTLS
Decide where TLS ends: at the gateway, at the upstream, or both. For partner and service-to-service traffic, specify mutual TLS and who issues and rotates client certificates. Confirm the gateway supports the cipher suites and protocol versions your policy requires, and that certificate expiry raises an alert before it causes an outage. Ask the partner to show the certificate lifecycle in a test environment, not just in a diagram.
Secrets for the Admin API and plugins
The Admin API can change every route and plugin, so its key is the most sensitive credential in the platform. Store it and plugin credentials such as client secrets in a dedicated secrets manager, not in configuration files committed to Git. Specify rotation intervals, who can read secrets, and how a leaked key is revoked without redeploying the gateway. Confirm what the chosen mode writes to disk and to etcd or the database.
Admin access and separation of duties
Separate the people who define routes, the people who approve them and the people who operate the infrastructure. Require named administrator accounts, role-based access in the management interface, and a second approver for changes to authentication plugins and upstream targets. Ask how Kong Manager and the APISIX dashboard, if used, are authenticated, and whether that access is logged separately from client traffic.
Network placement and trust boundaries
Place the data plane in a network zone that clients can reach, and keep the control plane, etcd or database and Admin API on a restricted internal segment. The Admin API ports, 9180 for APISIX traditional mode and 8001 for Kong, must never be exposed to clients or the internet. Document each trust boundary, the firewall rules that enforce it, and which identity provider and upstream services the gateway may reach.
Security event logging
Log authentication failures, rejected tokens, rate-limit blocks, configuration changes and Admin API calls, and forward them to a central store that the gateway team cannot edit. Define retention with your compliance owner, since the AI Act sets a six-month minimum for certain high-risk AI system logs, which may apply if the gateway fronts such a system. Confirm which fields include client identity and which redact tokens and personal data.
Limits of gateway enforcement
A gateway can verify tokens, enforce scopes, limit rates and validate schemas, but it does not know whether a user may read a specific record. Object-level authorization stays in the application, so each backend must check ownership of the object requested. Write this split into the design, assign owners for each control, and ask the partner to test the application layer as well as the gateway.
Choosing deployment mode and control plane location
This sequence settles where the gateway's configuration lives, which deployment mode fits that answer, and whether any control component reaches outside the organization's infrastructure. The output is a written topology decision that the architecture and security teams can sign off on before any cluster is built.
Write down the residency and blast radius rules
The security lead and the data protection owner state, in writing, which parts of the gateway may run outside the organization's own cloud accounts or data centers, and whether route configuration, logs and credentials count as regulated data. The architect records how many gateway nodes can fail together before partner or customer traffic is affected. The step is done when these rules are approved and can be tested against a proposed diagram.
Map the candidate APISIX deployment modes
The architect compares APISIX's three documented modes against the rules from the previous step. Traditional mode runs data and control plane together, decoupled mode separates a data plane from a control plane that share one etcd cluster, and standalone mode drops etcd entirely and loads configuration from
apisix.yamlorapisix.json, with a check for changes every second and a hot reload. Standalone mode suits teams that keep route definitions in Git and deploy them through a pipeline, but it puts configuration management on that pipeline. The output is a short table of modes against residency, failure and operations trade-offs.Map the candidate Kong topologies
The same comparison is run for Kong Gateway's self-managed topologies: traditional mode, where all nodes connect to a database, DB-less mode, where configuration is held in memory, and hybrid mode, which separates control and data planes. The team confirms which of these fit its licensing and support plan, because the OpenID Connect plugin is an Enterprise tier feature and is not part of the open source gateway. The output is a topology option list tied to specific plugins the organization needs.
Locate the control plane and every external dependency
For each candidate, the architect lists where the control plane runs, where its data is stored (etcd, PostgreSQL or files in Git), and which management services it calls. Kong Konnect is a cloud control plane for managing gateways, so any design that uses it must be checked against the requirement that control stays inside the organization's infrastructure. Teams should confirm with Kong which Konnect features, telemetry and metadata leave the environment, and whether a self-managed alternative covers the same need. The output is a dependency inventory with a yes or no for each external connection.
Test failure scenarios on the chosen topology
The engineering lead walks through failure cases for the shortlisted design: loss of the control plane, loss of the etcd or database cluster, a bad configuration push, and a compromised data plane node. For each case the team records whether live traffic keeps flowing, whether configuration can be changed, and how a rollback is performed. The step is complete when the results are documented and the owners accept the remaining risk. Teams should ask the implementation partner to run this review against a lab copy of the design.
Confirm ports, network zones and admin access
The network engineer maps the ports the chosen mode uses, for example APISIX's client traffic on 9080 and Admin API on 9180 in traditional mode, or Kong's proxy, Admin API and Kong Manager ports, and assigns them to network zones. Admin interfaces are restricted to management networks, and the team confirms that no administrative endpoint is reachable from partner or internet segments. The output is a reviewed firewall and zone diagram signed off by the security team.
Record the decision and confirm version support
The architect writes a decision record that names the chosen mode, the control plane location, the excluded external services, and the reasons for each. The record also states the product line and support status that the team relies on, checked against the vendor's current version support policy. This includes confirming which releases are long-term support and whether the open source line will meet the upgrade schedule. The step closes when the record is approved and stored with the architecture documentation.
Which release line and support window to require
Release line decides how long your gateway stays supported without a forced migration, so the checklist should name a release line and a support window before any build starts. A gateway sits on the path of every API call, so an unplanned upgrade is an outage risk. Ask each candidate to state which line it will deploy, when that line stops receiving fixes, and who carries the patch burden in between. The latest release is not the same as a supported release, and the two should not be treated as interchangeable in a contract.
For Apache APISIX, the latest release supplied is 3.19.0, released on September 28, 2026. The downloads page does not mark any release as long-term support, so confirm with the project and with your partner which line they will freeze on, how long security fixes for that line will be backported, and what the upgrade path looks like. For Kong, the open source repository stays on the 3.9 line, with 3.9.4 released on October 12, 2026. Kong Gateway Enterprise is a separate support track: its version support policy lists 3.10 and 3.14 as LTS releases, and Kong Gateway 3.9 reaches end of sunset support on December 12, 2026. Confirm those dates directly with Kong before you commit to an open source line that ages out of the commercial support cycle.
Require a written upgrade and backward compatibility policy from any partner, covering supported versions, how plugin and configuration changes are tested against your routes, and how a rollback is run. Ask the partner to show how an upgrade of a non-production environment is proven before production, and who signs off. Support dates change, so verify every date in this section with each vendor at the time of contracting.
Operational requirements and how to verify them
This table lists the operational requirements a self-hosted gateway must meet after go-live, with what good looks like and how to verify each one. Use it to turn vague expectations into tests your team and implementation partner can run before production. Availability targets should come from your own business requirements, not from a generic figure.
| Requirement | What good looks like | How to verify |
|---|---|---|
| High availability and failover | Multiple data plane nodes behind a load balancer, with no single etcd or PostgreSQL node whose loss stops routing. Failover behavior is documented for each deployment mode. | Stop one node per tier during a load test and record errors, latency and recovery time against the availability target your business set. |
| Backup and restore of configuration | Routes, upstreams, consumers, plugins and certificates are restorable from a recent backup in a separate failure domain. For APISIX traditional or decoupled modes this means etcd snapshots; for Kong database modes, PostgreSQL backups. | Restore into a clean non-production environment and confirm the route count, plugin settings and a sample authenticated request match production. Record the restore time. |
| Configuration in version control | Gateway configuration is declared in files kept in Git, with reviews and an audit trail, so the running state can be rebuilt from the repository. | Compare a live export of routes and plugins with the repository and confirm drift is detected and corrected through the pipeline. |
| Upgrade and rollback procedure | A written runbook covers staged upgrades across non-production and production, a compatibility check of plugins, and a tested path back to the previous version. | Run a full upgrade and rollback in staging, timing each step and confirming that existing routes and authentication still work after each change. |
| Capacity testing | Load tests use traffic shapes that match your peak patterns, including authentication overhead and rate-limit plugins enabled, with headroom documented for growth. | Run sustained and burst tests with production-like plugins, then confirm CPU, memory and connection limits at the point where latency rises. Ask your partner to supply the test scripts. |
| Observability: metrics, access logs and tracing | Request rate, error rate, latency, upstream health and authentication failures are collected, with access logs shipped off the node and traces linked to upstream services. | Trigger known faults such as an expired token, a blocked client and an unhealthy upstream, then confirm each appears in dashboards, logs and traces within the agreed window. |
| On-call ownership and runbooks | A named team owns the gateway, has escalation paths to identity and network owners, and has runbooks for certificate expiry, node failure and rate-limit incidents. | Review the on-call roster and run a tabletop exercise for one failure scenario, checking that responders can find the runbook and reach the right people. |
| Disaster recovery | A documented recovery plan states which region or site takes over, how DNS or load balancer routing switches, and how configuration and secrets are restored. | Perform a recovery drill at least once before go-live and record the achieved recovery time and any manual steps, comparing them with your recovery objectives. |
| Certificate and secret lifecycle | TLS certificates, identity provider client secrets and upstream credentials have owners, rotation schedules and alerts before expiry. | List every credential with its owner and expiry date, then confirm a rotation can be completed without downtime in a test environment. |
Compliance and sector standards to map before selection
Map FAPI 2.0, PCI DSS 6.4 and HIPAA before selecting a gateway, because each one changes what the gateway must enforce and where it must sit. FAPI 2.0 applies to financial-grade APIs such as open banking and partner access. Its security profile expects strong client authentication and sender-constrained tokens, often with mutual TLS, so confirm with the specification and your assessor which checks the gateway performs and which stay in the authorization server or the application. PCI DSS 6.4 concerns protection of public-facing web applications and APIs, and whether the gateway falls inside cardholder data scope is a decision for your qualified security assessor. For HIPAA, the relevant controls cover transmission security, integrity and audit controls on PHI routes, so confirm which routes carry PHI, where TLS terminates, and whether access logs capture the events you must retain.
The EU AI Act adds a logging duty when an API fronts a high-risk AI system. Article 12(1) requires such systems to technically allow automatic recording of events over their lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. A gateway in front of an AI service can produce part of that record: caller identity, route, timestamp, status code and request identifier, which can be correlated with model-side logs. Whether gateway logs alone satisfy the duty depends on how the system is classified and what the model layer records, so confirm this with your legal and AI governance owners before the logging design is fixed. Decide early where logs are written, how long they stay on hot storage, and whether retention meets the six-month minimum or is extended by other law.
The evidence a gateway can produce is mostly configuration and logs. With Apache APISIX in file-driven standalone mode, routes and plugins live in conf/apisix.yaml or conf/apisix.json, so keeping that file in Git gives a change history with reviewers and timestamps. Kong's DB-less and hybrid topologies offer comparable declarative control, though you should confirm the exact export and audit features in the version you deploy. Access logs, plugin settings and exported configurations form the evidence set an assessor will sample. One gap to resolve early: Kong's OpenID Connect plugin is an Enterprise tier plugin, so an open-source Kong design needs another way to validate tokens, and that choice changes the authentication evidence you can show. DeployOpen prepares controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work.
How much work does an API management implementation need from us?
What drives the cost of an API management implementation?
The main cost drivers are the number of APIs and environments, how many identity integrations are needed, whether custom plugins are required, whether a developer portal is in scope, and how much compliance evidence the work must produce. Each one adds design, configuration, testing and documentation effort. Infrastructure is a separate line: the gateway itself is open source, so spend moves to servers or cluster capacity, monitoring and the people who run them. Ask for a quote that lists each API group, each identity provider, each plugin and each environment as separate line items, and that states which items are one-time (design, build, migration, hardening) and which recur (upgrades, support, testing). No supplied figure sets a price, so the written scope is the basis for any number.
Can our internal team run an API gateway without outside help?
Often yes, for a small estate with one identity provider and a few APIs, if the team already runs Kubernetes or Linux services and can manage configuration as code. The work becomes harder as the estate grows. Apache APISIX documents three deployment modes, traditional, decoupled and standalone, and Kong Gateway documents traditional, DB-less and hybrid topologies, so the team must choose a mode and then operate its data and control planes, certificates, upgrades and backups. Some features are outside the open source edition: Kong's OpenID Connect plugin is Enterprise tier, and Kong Konnect is a cloud control plane. Confirm the feature list against the edition you plan to run before deciding who builds what.
How long does an API gateway rollout take, and what does it depend on?
The timeline depends on the number of APIs to inventory and migrate, how many identity providers must be connected, whether consumers must move without downtime, and how many approval gates the change process has. No supplied fact gives a duration, so ask the partner for a phased plan with dates tied to named milestones: inventory, design, a pilot with a small set of routes, migration in waves, and retirement of old routes. Ask which of those steps depend on another team's work, such as identity configuration or firewall changes, since those dependencies usually set the critical path more than the gateway configuration does.
What do we need to provide during an API management engagement?
Three groups of people are needed in most engagements:
- Identity owners, who provide the OIDC or OAuth client registrations, scopes, token lifetimes and certificate authorities used for mutual TLS.
- API owners, who confirm each API's paths, schemas, consumers, rate limits and version policy, and who sign off on routing changes.
- Network and change approvers, who open firewall rules, DNS entries and load balancer paths, and who approve production changes.
Ask the partner to name the decision owner for each item and to list these dependencies in the scope, with the date each one is needed. Missing identity or API owner input is the most common reason for delays, so it should appear in the written plan.
Should we build, partner or buy a SaaS API platform?
Build means your staff own the gateway, partner means an outside team implements and supports a self-hosted gateway in your infrastructure, and SaaS means a vendor runs the control plane or the whole service. Build suits teams with steady platform capacity and a narrow feature set. A partner suits organizations that need the gateway deployed, integrated and hardened quickly, while keeping data and traffic in their own cloud accounts or data centers. SaaS suits teams that accept a vendor-hosted control plane and fit its pricing model, which is often per call or per subscription. Decide based on where your traffic and configuration may reside, which identity and audit evidence you must retain, and who will carry the upgrade calendar.
How do we request a fixed-scope quote for API management?
Send the partner a written inventory of the APIs in scope, with traffic estimates, consumer types, identity providers, deployment targets, and any sector standards such as FAPI or FHIR requirements. Ask for a fixed-scope proposal that lists deliverables, acceptance criteria, environments, exclusions, client responsibilities and timeline milestones. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and most engagements are fixed-scope. Quotes follow from that written scope, and DeployOpen does not publish a price list, so compare proposals on scope clarity rather than headline figures. Ask separately for ongoing support, upgrades and testing as a retainer.
What compliance evidence adds effort to an API gateway project?
Evidence work adds effort when auditors or regulators need proof of how the gateway behaves. Typical items include configuration in version control with approval history, access logs retained for the period your rules require, documented authentication flows, certificate and key management records, and test results for rate limits and access controls. The work is to design these artifacts and collect them from the start, not to assemble them at audit time. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications, so ask your assessor which artifacts they will accept and include those in the scope.
How DeployOpen scopes and delivers an API management requirements review
DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, so the requirements review starts from where your APIs, identity provider and control plane will actually run. We turn the checklist into a written scope, then deliver the design, configuration and evidence that the decisions require.
How we scope
- Inventory the APIs, traffic volumes and partner groups that the gateway must carry before choosing a product.
- Map authentication needs across OIDC, API keys and mTLS to the identity provider and client types you already run.
- Agree in writing which deployment mode, control plane location and versioning approach are in and out of scope.
How we build
- Prototype the chosen gateway, such as Apache APISIX or Kong Gateway, against a representative subset of your routes and policies.
- Document rate limit rules, observability sinks and developer portal or partner onboarding flows as testable configuration.
- Test the gateway configuration with security checks covering the OWASP API risks that a gateway can enforce.
How we hand over
- Deliver the API inventory, architecture diagrams and configuration kept in version control, with the reasoning behind each decision.
- Provide runbooks for deployment, certificate rotation, plugin changes and gateway upgrades in your environment.
- Walk your platform, security and identity teams through the operating model so they can run the gateway without us.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer once the gateway is in production.
- Review new APIs and partner onboarding requests against the agreed requirements and update the inventory.
- Confirm with your compliance and audit teams which evidence they need, since DeployOpen prepares evidence but does not issue audit reports or certifications.
