3 questions from the package
From the RFI round. The first shows part of the guide each question carries; the workbook adds follow-ups, how to verify the answer, a priority and a weight.
1. Show route definitions that match requests by host, path, HTTP method and header value, with separate routes for two versions of the same API.
Why it matters. If routes cannot match on all of these attributes, the buyer has to deploy extra gateways or proxies to separate API versions and tenants. Version-specific routes are what allow an old and a new version to run side by side.
Good answer
- One route definition combines host, path, method and header conditions
- Two routes for v1 and v2 of one API send traffic to different backends based on a header or path segment
- The documentation states the matching order when more than one route could match a request
Red flags
- Header-based matching requires custom code or a plug-in
- Matching precedence is undocumented or depends on the order routes were created
- Each API version needs its own gateway or domain
2. Can a rule on one API allow or block requests by client IP address range?
Why it matters. Without per-API network rules, the buyer must enforce partner IP allow lists and country blocks in a separate layer from the API's other policies.
3. Does the product detect unusual traffic from an individual consumer, such as sudden volume spikes, repeated failed authentication, or systematic data scraping?
Why it matters. Static rate limits do not catch abuse that stays under the limit, such as slow scraping or credential stuffing with a valid application key. Without per-consumer detection, the buyer finds this only after data has left.
Capability areas
Gateway routing, traffic control and performance (17)
Routing by host, path, method and header; rate limits and quotas with 429 responses and cluster-wide consistency; circuit breaking, load balancing, retries, timeouts, caching, canary splits, body-size limits and traffic mirroring. Also covers added latency, scale-out, configuration propagation, zero-downtime upgrades, multi-zone operation and documented capacity limits; plan definitions and billing belong to MON.
Authentication, credentials and transport security (13)
OAuth 2.0 access-token validation (JWT and introspection), working with an external authorization server, built-in client-credentials issuance, the API key lifecycle and revocation speed, inbound and backend mutual TLS, IP and country rules, CORS, TLS version and cipher control, key-cache behavior during identity provider outages, and hashed or encrypted credential storage. The vendor's own corporate security posture belongs to the security module.
Runtime threat protection (10)
Schema validation of requests against the OpenAPI definition, injection and malformed-payload blocking, limits on JSON and XML nesting and size, per-consumer anomaly detection (spikes, credential stuffing, scraping), bot detection, and the product's coverage of the OWASP API Security Top 10 as tested with attack traffic. Authentication mechanics are in AUT.
Policies, transformation and extensibility (11)
Policy attachment at the global, API, operation and consumer levels with a defined precedence; header, query and path rewriting; JSON and XML body transformation; field masking in responses and logs; consistent error formats; mock responses from the specification; multi-backend aggregation; and custom policy logic or plug-ins without forking the gateway.
Protocols and API styles (10)
Management of REST over HTTP/1.1 and HTTP/2, GraphQL with depth and complexity limits, gRPC, WebSocket, SOAP and SOAP-to-REST mediation, event-driven APIs described in AsyncAPI with access control to brokers or streams, and outbound webhooks with signing, retries and delivery status. General-purpose integration flows outside the gateway are out of scope.
API design, versioning and lifecycle (11)
OpenAPI import and export and the generation of gateway configuration from it, the specification editor, style-rule checks before publishing, side-by-side versions and revisions, breaking-change detection, deprecation with retirement dates and consumer notification, and lifecycle states with approvals.
Developer portal and consumer onboarding (13)
The portal catalog and generated reference docs, developer sign-up and application registration, access requests with approval routing, try-it calls with the developer's own credentials, per-developer usage views, self-service credential rotation, visibility rules by developer, team or partner organization, portal single sign-on, branding and guide content, code samples, portal content languages, and portal availability during control-plane maintenance. WCAG conformance belongs to the accessibility module.
Analytics, logging and observability (11)
Traffic, latency, error and status-code reporting by API, operation, consumer and application; per-request logs with correlation IDs and body logging controlled per route; OpenTelemetry and other exports; threshold alerts; separation of gateway latency from backend latency; analytics freshness and retention; tamper-proof request logs streamed to a SIEM; and request handling when the log destination is slow.
API products, plans and monetization (8)
Bundling APIs into products with plans that set quotas, limits and terms; usage metering and export for billing; charging through an external billing system; plan changes without new credentials; agreement between metered usage and request logs; and in-product reporting of usage in the unit the license is measured in. Contract pricing terms belong to the commercial module.
Governance, inventory and audit (10)
A catalog of managed APIs with owner, state, version, consumers and gateways; discovery of unmanaged APIs from traffic, gateways or repositories; federation of gateways from other sources under one control plane; per-API access review with last-call dates and revocation; and an immutable audit log of configuration and permission changes with before and after values and retention. Also whether the same control plane applies policy to east-west (service-to-service) traffic, for buyers converging API management and service mesh.
Hybrid deployment, automation and administration (13)
One control plane over gateways in vendor-hosted, customer-cloud, on-premises and Kubernetes environments; gateway operation during control-plane disconnection; configuration as code in Git with CI/CD and environment promotion; admin API, CLI and admin API rate limits; admin roles scoped to chosen APIs or teams; certificate and secrets-manager integration; backup and restore; import from a current API management tool; credential moves to a successor product; supported platform versions; and notice of breaking changes. Hosting regions and tenancy belong to the deployment-hosting module.
AI and agent traffic (9)
Managing calls from applications to LLM providers through the gateway (token-based limits, provider routing and failover, prompt and response inspection, cost attribution per consumer) and exposing managed APIs to AI agents as tools with scoped authorization and per-agent traffic control. AI features used inside the vendor's own console are covered by the AI modules.
