---
title: "API Governance"
description:
  "Define security and compliance policies once, apply them across every route,
  enforce them in CI before merge. SOC 2 Type II, immutable account audit logs,
  RBAC for the management plane, fine-grained API key scopes. GitOps-native —
  every change reviewed in a PR."
canonicalUrl: "https://zuplo.com/features/api-governance"
sourceUrl: "https://zuplo.com/features/api-governance"
pageType: "feature"
generatedAt: "2026-08-03"
---

# API Governance

> Zuplo lets you define security and compliance policies once, apply them across
> every route, and enforce them in CI before merge. It's SOC 2 Type II
> certified, with immutable account audit logs, RBAC for the management plane,
> fine-grained API key scopes, and a GitOps-native model where every governance
> change is reviewed in a PR.

## Why this matters

Governance by Slack message doesn't survive the next audit. When policy lives in
conventions instead of code, every team interprets it differently. The auditor
finds the gap. The compliance review extends the launch. The CISO loses sleep.

- **Each team enforces its own definition of "production-ready."** Three teams,
  three rate-limit conventions, three logging formats. Auditors ask "how do you
  ensure all APIs require auth?" and the honest answer is "we Slack each team
  and hope."
- **Compliance reviews block ship velocity.** A new endpoint takes two
  engineering days to implement and two weeks to clear "the security review."
  The slowdown is the cost of not having policy enforced automatically.
- **Audit logs scattered across five places.** Authentication logs in Auth0,
  gateway logs in CloudWatch, app logs in Datadog, deploy logs in GitHub,
  account changes in your IDP. Compiling a single audit trail for one customer
  takes a sprint.
- **"Who changed the prod rate limit at 2am?"** A control-plane click changed
  something critical. There's no PR, no diff, no immutable audit. Engineering
  manager spends Monday morning piecing together the timeline from Slack DMs.

## What you get

Define it once. Enforce it in CI. Audit it forever.

- **One policy, every route.** Define rate limits, auth, schema validation, and
  audit logging once as a shared policy or composite. Reference it from every
  route. Update it once — every route inherits.
- **Enforced in your PR, not after deploy.** Config is files in Git. CI runs
  your governance checks before merge — auth required on every route, no inline
  rate limits (must use a shared one), schema validation on body-bearing
  requests. Violations block the merge.
- **SOC 2 audit, not Slack archaeology.** Every config change is a Git commit.
  Every account action is in the immutable audit log with full actor and
  resource context. Every gateway request is logged with caller identity and
  exported to your SIEM. One place per dimension, all queryable.

## One bundle. Every route. Reviewed in a PR.

Wrap your "production-ready" requirements into a single named Composite Inbound
policy. Apply it to every public route. Run a governance check in CI to fail any
PR that ships a route without it.

```json
{
  "name": "production-ready-inbound",
  "policyType": "composite-inbound",
  "handler": {
    "export": "CompositeInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "policies": [
        "api-key-auth-inbound",
        "rate-limit-prod",
        "request-validation-inbound",
        "audit-log-datadog"
      ]
    }
  }
}

# Apply to every route in routes.oas.json:
#   x-zuplo-route.policies.inbound:
#     - production-ready-inbound
```

```bash
# .github/workflows/governance.yml
- name: Enforce production-ready policy
  run: |
    node scripts/check-governance.mjs

# scripts/check-governance.mjs (excerpt):
for (const [path, route] of Object.entries(routes.paths)) {
  for (const [method, op] of Object.entries(route)) {
    const policies = op["x-zuplo-route"]?.policies?.inbound ?? [];
    if (!policies.includes("production-ready-inbound")) {
      console.error(`${method.toUpperCase()} ${path}` +
        " missing production-ready-inbound");
      process.exit(1);
    }
  }
}
```

Key pieces of the model: shared policies, Composite Inbound, OpenAPI as the
source of truth, PR review + branch protection, SOC 2 Type II, and RBAC (Admin /
Dev / Viewer).

## What makes Zuplo different

- **OpenAPI is the source of truth.** Routes live in `config/routes.oas.json` —
  a standard OpenAPI document with `x-zuplo-*` extensions for handlers and
  policies. Lint with Spectral in CI, generate clients with Speakeasy or
  RateMyOpenAPI, write tests against the schema. The gateway and the docs and
  the SDKs all read the same file.
- **Composite policies as governance bundles.** Bundle "production-ready" into a
  Composite Inbound policy: api-key-auth → rate-limit-prod → request-validation
  → audit-log-export. Apply the composite to every public route. New routes
  inherit the full policy stack with one line — no opportunity to forget a step.
- **Account-level immutable audit.** Every project mutation, deployment, team
  change, API key operation — captured with full actor (sub, email, IP, geo,
  ASN), resource (type/ID), and outcome. 90-day default retention, query via
  Developer API, export to your SIEM. Pre-baked for SOC 2 evidence collection.
- **Data residency on your terms.** Managed Edge for global low latency. Managed
  Dedicated single-tenant on the cloud and region of your choice (EU-only,
  US-only, regulated cloud) when sovereignty requires it. Self-Hosted on your
  Kubernetes when nothing leaves your perimeter. Same policies, every surface.

## What teams use this for

**"Auditor needs proof every API requires authentication."** Show them
`config/policies.json` (one shared `api-key-auth-inbound` policy), the Composite
Inbound bundle that includes it, and your CI script that fails if any route
doesn't reference the composite. Three files, one queryable Git history, one
minute.

**"We need to roll out a new rate limit across 47 routes."** Update the shared
`rate-limit-prod` policy in one place. Every route that references it inherits
the new value. Open a PR. Reviewers see one diff, one test run, one merge —
instead of 47 individual changes.

**"Customer wants 12 months of audit logs for a SOC 2 review."** Export the
account audit log via the Developer API to your S3-backed log archive. Combined
with gateway logs in your SIEM (Datadog, Splunk, etc.), you have an immutable
trail covering both control-plane changes and data-plane traffic — exactly what
the auditor wants.

**"Force partners off a deprecated API version on a known schedule."** Attach
the Brownout policy to the deprecated routes. It returns scheduled 503s during
specified windows — first an hour a week, then a day, then full sunset — so
partners feel the deprecation as concrete downtime instead of an email they
ignored. The policy lives in your repo with a date-driven config; no last-minute
pull-the-plug ops.

## FAQ

**What is API governance?** API governance is the practice of enforcing
consistent rules — auth, rate limits, schema validation, logging, deprecation —
across every API in your organization. Without it, each team ships its own
version of "production-ready" and auditors get vague answers. Zuplo treats
governance as code: shared policies you define once, apply to every route, and
validate in CI before merge. SOC 2 evidence, audit trails, and policy
enforcement become a Git history instead of a Slack archaeology dig.

**How do you enforce consistent policies across every API?** Define each policy
— auth, rate limit, schema validation, audit logging — once as a shared resource
in your gateway config, then reference it by name from every route. Bundle the
common stack into a Composite Inbound policy and apply the bundle in one line
per route. New routes inherit the full policy stack automatically; updates roll
out to every route the moment you merge. Zuplo's GitOps-first model means every
governance change is a reviewable PR.

**Is Zuplo SOC 2 compliant?** Yes — Zuplo is SOC 2 Type II certified. The
current report and Trust Center are published at trust.zuplo.com. Beyond Zuplo's
own posture, the platform is built to support your SOC 2, HIPAA, and enterprise
security reviews: immutable audit logs, RBAC for the management plane,
encryption at rest and in transit, GitOps-based change history, and exportable
audit trails to your SIEM.

**How do I get an audit trail of who changed an API config?** Every config
change in Zuplo is a Git commit — author, diff, message, timestamp — so the
answer to "who changed the prod rate limit at 2am" is one git blame away. On top
of that, the account-level audit log captures every project mutation,
deployment, team change, and API key operation with full actor identity (email,
IP, geo) and resource context. 90-day default retention, immutable, queryable
via the Developer API, exportable to your SIEM.

**How do I enforce API security policies in CI before merge?** Because Zuplo's
config is files in your Git repo, any rule you can write as a script can run in
CI. Common patterns: every route must reference an auth policy, no inline rate
limits (must use a shared one), schema validation required on body-bearing
requests, audit-log policy on every public route. Wire the script into a GitHub
Action and block the merge if it fails. Governance becomes a guardrail, not a
quarterly review.

**How do you keep API data in a specific region for compliance?** Zuplo offers
three deployment models depending on how strict your data residency needs to be.
Managed Edge runs across 300+ data centers globally for low latency. Managed
Dedicated is a single-tenant instance in the cloud and region you choose —
EU-only, US-only, regulated cloud, etc. Self-Hosted runs on your own Kubernetes
when nothing leaves your perimeter. Same policies, same dashboards,
contractually enforced location.

**How do I enforce API deprecation and force partners off old versions?** Most
teams email a deprecation notice and pray. Zuplo has a Brownout policy that
turns deprecation into scheduled downtime — attach it to deprecated routes with
a ramp (one hour weekly, then a day, then full sunset) and partners feel
concrete 503s during the window. Combine with Deprecation headers and the
developer portal's banners and partners get a structured, dated path off the old
version. Schedule lives in your repo, reviewable in a PR.

**What's the best API gateway for SOC 2 and enterprise compliance?** Look for
SOC 2 Type II certification, GitOps-native config (so every change is
auditable), immutable account audit logs, RBAC for the management plane,
exportable logs to your SIEM, and configurable data residency. Zuplo ships all
of these out of the box and is used by regulated customers in fintech,
healthcare, and banking — including BancoSol, LMCU, and BlockDaemon. Talk to a
Zuplo compliance expert to walk through your specific framework.

## Next steps

- Start a free account: https://portal.zuplo.com/signup
- Read the Policies Guide: https://zuplo.com/docs/articles/policies
- Talk to a Compliance Expert: /schedule-call
- Read Trust & Security: https://trust.zuplo.com/
