Policy model

A policy document configures a policy type compiled into the gateway. Policy instances are always owned by an API Bundle or Shared Flow Bundle revision; they are never independent deployment artifacts.

kind: Policy
name: orders-quota
type: quota/v1
enabled: true
condition: request.method == "POST"
onError: fault
config:
  identifier: "{token.appId}"
  limit: 1200
  window: 1h
  store: redis

Policy type versus instance

• quota/v1 is a policy type implemented and registered by the gateway.
• orders-quota is a policy instance whose configuration is frozen into one bundle revision.
• A flow step references the policy instance by name.

Types are explicitly versioned. There is no implicit latest, which prevents a gateway upgrade from silently changing the meaning of published configuration.

Conditions

Policies and flow steps may carry conditions. When both exist, both must evaluate to true.

- policy: orders-quota
  condition: system.environment == "prod"
  onError: fault

Conditions support comparisons, &&, ||, !, parentheses, and glob matching with =~. Missing variables evaluate as null and do not throw.

Error behavior

onError is deliberately small:

• fault enters the bundle fault pipeline.
• continue records the step failure and advances.

Policy-specific fallback behavior belongs in the policy’s own configuration only when its schema defines it.

Schema source of truth

Every type has a machine-readable manifest under schemas/policies/. The manifest declares its display name, supported phases, default configuration, deprecation state, and configuration schema. The management API exposes the same catalog for the admin editor and other tooling.