How to choose an API management platform for a regulated enterprise

Most API management platform evaluations in a regulated enterprise end the same way. Every shortlisted vendor answers yes to nearly every RFP row, and the decision gets made late, by the CISO or the risk committee, on a question the spreadsheet never asked: where does the control plane run, and what evidence comes out of it?

A management plane in a vendor's cloud can fail a data residency review that happens after procurement. A partner portal sold as a separate product can push onboarding into a ticket queue, and an audit trail sold as an add-on can leave the first regulator visit dependent on stitching logs together.

This guide turns enterprise API management requirements into eight evaluation questions: what a good answer looks like, how Zerq answers (including where it does not), and which test in a two-week proof of concept checks it.

Why feature tables pick the wrong API management platform

An API management platform comparison built on feature rows rewards breadth. Most serious vendors have a portal, OAuth, analytics and some hybrid option. What separates them sits underneath: which plane runs where, how many separately deployed products make up the platform, and whether a reviewer can pull evidence unaided.

Apigee hybrid runs the runtime plane in your Kubernetes clusters while the management plane stays in Google Cloud. The Azure API Management self-hosted gateway processes traffic locally but takes configuration from the Azure-hosted instance, which also serves the portal. AWS API Gateway is a regional managed service: private APIs are reachable only from your VPC through an interface endpoint, but the runtime runs in AWS and you cannot install it yourself. MuleSoft runs Mule runtimes on your infrastructure with the Anypoint control plane usually hosted by MuleSoft, and orchestration means building Mule applications.

Kong, Tyk and WSO2 can be fully self-hosted, which moves the evaluation to assembly. Kong extends its gateway through plugins and offers Konnect as a vendor-hosted control plane. Tyk ships gateway, dashboard and portal as separately deployed components. A distributed WSO2 API Manager splits into control plane, gateway and traffic manager components with their own scaling and patch cycles. Each is a legitimate trade-off; the questions below test whether it fits your boundary, and the compare pages go vendor by vendor.

A reference architecture to evaluate against

Before scoring vendors, draw the target. A regulated Zerq deployment has four zones.

The edge zone is your load balancer or ingress: it terminates TLS, validates client certificates for mtls profiles and, for certificate-bound tokens, forwards the certificate in a header (X-SSL-Client-Cert in our reference setup). Only the ingress may set that header. Put the backend on a network that only the ingress can reach, because in the default Compose topology other containers can call the backend directly and forge it. The ingress should also strip any caller-sent X-Proxy-ID header, which Zerq treats as a test-console call and leaves out of request logs.

The platform zone holds the backend, one Go service serving the gateway runtime, the management API under /api/v1, the Developer Portal API, Gateway MCP at /mcp and Management MCP at /api/v1/mcp, plus the separately scaled management UI and developer portal. The state zone holds MongoDB (configuration, request logs, audit logs), Redis or KeyDB (cache and multi-pod coordination) and your OIDC provider, such as Keycloak.

The outbound zone is short: upstream services, an SMTP relay for portal sign-in emails and, only with Zerq Copilot enabled, an LLM endpoint that can be a local Ollama model. A runtime call passes the edge, clears gateway checks on policy, credential, IP, method and collection before any workflow runs, goes upstream and leaves a request log. A management change carries an OIDC bearer token through a role check into MongoDB and leaves an audit log entry your SIEM can pull through the audit log API. See the architecture page.

The API management requirements that decide the outcome

Where does the control plane run?

Ask where every component runs: gateway, management API, portal, analytics, audit store and any AI assistant. A good answer names your network for all of them. In Zerq, control plane and data plane are one deployment inside your boundary, on Docker Compose or Kubernetes, and offline installs run from transferred images with pinned tags. Beyond your upstreams and an SMTP relay for portal sign-in emails, the one optional outbound dependency is the Copilot LLM, which can be a local Ollama model. Tests 1 and 12.

How are consumers identified, and how finely?

Zerq models a consumer as a client (the organization) with one or more profiles (a credential plus constraints). Every call carries X-Client-ID, X-Profile-ID and a credential for the profile's auth type: token, jwt, oidc, mtls or none. Each profile has its own allowed methods and IP restrictions, so a partner can hold a read-only production profile beside a sandbox one. IP restrictions see the direct peer, so behind an ingress, enforce source ranges at the ingress. Rate limits and quotas live in a policy on the client, shared by its profiles.

Ask two things. Who validates client certificates? For Zerq mtls profiles, your ingress does. Can tokens be bound to certificates? On oidc profiles, yes: Zerq checks the RFC 8705 cnf.x5t#S256 claim against the forwarded certificate, set through the API because there is no dashboard toggle yet. DPoP is not supported, and tokens come from your IdP. See the security page. Tests 4 to 7.

Can partners self-serve without self-registering?

Regulated programs usually want managed onboarding, not open sign-up. The Zerq Developer Portal has no self-registration: an operator enables portal access on the client and lists authorized emails. Partners sign in with a single-use magic link, see only collections assigned to their client, test from a console pre-filled with their profile's headers, and download OpenAPI 3.0 or 3.1. Consumer-created keys and app registration are a gap: credentials come from profiles an operator creates. Test 8.

Do AI agents use the same gateway?

Ask whether agent traffic needs a separate product and policy model. Zerq's Gateway MCP gives agents the same client, profile, limits and request log as REST callers. Operators' agents use Management MCP with their own OIDC token and role. Zerq does not proxy application traffic to LLM providers, so model routing belongs elsewhere. See AI gateway, LLM gateway or agent API gateway for where each sits. More on MCP access. Test 9.

Can you orchestrate without writing a service?

Merging two backends, translating XML or adding a fallback usually means a new microservice or a vendor policy language. Zerq attaches an optional workflow to a proxy: a graph of nodes such as http_request_node, condition_node, merge_node, xml_node and response_node, with templates for orchestration, transformation, resiliency and canary routing. Retries are composed from nodes, with no circuit-breaker node, so test the fallback you need. See workflow orchestration. Test 10.

What evidence does an auditor get?

Ask the auditor's questions: who changed this, who called that, and can the reviewer change anything? Zerq audit logs capture management changes (timestamp, actor, action, resource, URL, IP, request body, response status), readable only by the auditor role. Request logs capture runtime traffic with request ID (returned as X-Request-ID), client ID, profile ID, status and latency. The gaps: maker-checker approval is your change process, not a product step; request logs have no built-in PII masking; SIEM export means querying the audit log API for JSON. More on the observability page. Our runtime API governance framework maps each control to the evidence it leaves. Test 11.

How does it behave on a bad day?

Ask for the upgrade runbook and failure modes. Zerq's stateless services scale horizontally on Kubernetes, with MongoDB, Redis or KeyDB and the IdP as critical dependencies; backend pods stay in sync through Redis pub/sub. Upgrades are image pulls or Kubernetes rollouts, then acceptance checks on a protected route and both login paths. The dashboard shows success rate, errors and average latency, with no built-in alerting engine, so alert from your existing monitoring. Test 12.

What does the price count?

Ask what grows the bill: calls, gateways, users, partners, modules or environments. Zerq is licensed per deployment environment on a flat annual fee, from $18,000 a year for a single production environment, with no per-call, consumption or per-seat charges. Every plan includes the full platform, from gateway and workflow builder to portal, audit trail, AI agent access and Zerq Copilot, and the deployment model costs nothing extra. There is no free trial; a 60-day fixed-fee proof of concept is credited toward the first annual license. See pricing.

One config block that answers three RFP questions

Operator identity, the four roles (viewer, modifier, auditor, admin) and secret handling live in the backend environment:

# backend service environment (Compose or Kubernetes)
OIDC_ENABLED: "true"
OIDC_ISSUER_URL: https://idp.internal.example/realms/api-platform  # your IdP, on your network
OIDC_AUDIENCE: api-gateway-management
OIDC_ROLE_CLAIM_PATH: realm_access.roles     # where role names sit in the token
# Each list gates one route tier, so name every group that should pass it
OIDC_VIEWER_ROLES: platform-viewer,platform-operator,platform-admin
OIDC_MODIFIER_ROLES: platform-operator,platform-admin
OIDC_AUDITOR_ROLES: internal-audit           # reviewers only: in no write tier
OIDC_ADMIN_ROLES: platform-admin             # can delete log records; keep it small
ENCRYPTION_KEY: ${ENCRYPTION_KEY}            # AES-256 key for stored credentials, never in the database
MTLS_CLIENT_CERT_HEADER: X-SSL-Client-Cert   # header the ingress forwards the client cert in

Keeping internal-audit out of every other list is what makes "the people who review changes cannot make changes" true in practice.

Mirror the same role lists in the management UI's NEXT_PUBLIC_*_ROLES and ROLE_CLAIM_PATH. Gateway oidc profiles validate tokens against the separate GATEWAY_OIDC_ISSUER_URL and GATEWAY_OIDC_AUDIENCE settings.

A two-week proof-of-concept test plan

Run the same tests against every finalist and write each pass condition down first. A test without an expected status code is a demo.

Week 1: boundary, identity and access

Boundary install. Deploy pinned image tags inside the target network. Pass: operators sign in through your IdP and /readyz returns 200 (it checks MongoDB, and Redis when CACHE_TYPE=redis) with no outbound internet route.
Role separation. As a viewer-only user, try to create a collection. Pass: 403 from the management API, and only the auditor account can open Audit Logs.
Lifecycle. In Collections, click Import from OpenAPI and load one of your OpenAPI 3.x specs. Pass: imported proxies arrive in draft. After test 4, the partner's call returns 404 while they are draft and 200 once they are published with their collection.
Partner access. In Clients, click New Client, add a token profile limited to GET with one allowed IP, and assign the collection. Call the gateway directly for this test, since behind an ingress Zerq sees the ingress's address. Pass: valid call 200, wrong token 401, POST 405, other source address 403.
Limits. Attach a policy with a 1m rate limit of 10 requests to the client. Pass: the eleventh call in the window returns 429 with rate_limit_exceeded.
Revocation. Rotate the profile's credentials and replay the old token. Pass: 401 on the next request, no restart.
Certificate binding, if you need sender-constrained tokens. Set requireCertificateBoundToken: true on an oidc profile via the API or update_profile, and enable certificate-bound tokens in your IdP. Pass: a valid token without its certificate returns 401.

Week 2: portal, agents, evidence and operations

Partner portal. Enable Developer Portal access on the client and authorize one partner email. Pass: after magic-link sign-in the partner sees only the assigned collection and the testing console returns 200; an unlisted address gets no session.
Agent access. On the partner client, add an agent profile that allows GET and POST and either has no IP allowlist or allowlists the address the backend uses to reach GATEWAY_BASE_URL. Point an MCP client at /mcp with that profile's headers and token. Pass: list_collections shows only the assigned collection, an execute_endpoint call to an unassigned path returns isError: true with status 404, and every execute_endpoint call appears in Logs under the partner's Client ID.
Orchestration. In the proxy's workflow, click Use template, load the resiliency template, enable it and aim its first http_request_node at a stopped backend. Pass: callers get the fallback body defined in response_node, with nothing deployed.
Evidence. As the auditor, filter Audit Logs for the changes from tests 4 to 7. As a viewer, filter Logs by Client ID and 4xx. Pass: every gateway 401, 403 and 405 from tests 4, 6 and 7 appears with its Request ID, and the audit events reach your SIEM via the audit log API. The 429 responses from test 5 are returned before the request logger runs, so record them from the client side.
Bad day. Run two backend replicas under a request loop, delete a pod, then roll an image upgrade. Pass: valid calls stay 200, 401 and 403 behavior is unchanged, and the rollout completes. Then restore a deploy/mongodb.sh backup into a scratch environment.

Checklist for your API management RFP

Control plane, portal, audit store and AI assistant all run in a network you choose, air-gapped if needed.
Consumers authenticate as your partners already do, with per-credential method and IP limits and immediate revocation.
Partner portal access is granted by an operator and scoped to assigned APIs.
AI agents' API calls share the identities, limits and logs of REST callers.
Reviewers who cannot change configuration can read the change history, and every authentication and authorization denial is retrievable by request ID.
Price does not scale with calls, partners or modules, and the vendor's gaps are in writing before contract.

What this looks like in practice

A bank's platform team had three vendors within a few points of each other on its RFP. The top scorer paired a local gateway with a vendor-hosted control plane, and weeks before contract the risk committee asked where partner configuration and audit records lived, which reset the evaluation. Onboarding a partner meant a ticket, a manually issued key and a PDF of the spec.

The team rewrote the RFP as the eight questions and ran the twelve tests against two finalists in one fortnight. Test 1 settled the boundary in a day, and test 11 settled internal audit: their lead filtered the week's profile changes herself, from an account that could not edit anything. After rollout, onboarding meant a client, a profile and an authorized email, and the next review's evidence pack was two filtered views (Audit Logs by resource type and date, Logs by Client ID and 4xx) and an audit API export.

The short version

Choosing an API management platform for a regulated enterprise comes down to what feature tables skip: control plane location, consumer identity, partner access, agent controls, orchestration without code, evidence a reviewer can pull alone, behavior under failure and what the price counts. Write down the good answer, run every finalist through the same numbered tests, and buy the one that passes inside your boundary.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.