Policy Templates API

Use policy templates to bootstrap common governance rules instead of hand-authoring every tenant policy from scratch. This is especially useful when teams want to roll out repeatable controls for PII detection, SQL injection prevention, regional compliance, or industry-specific AI safety requirements.

Overview

Verified routes:

Method	Path	Purpose
`GET`	`/api/v1/templates`	List templates
`GET`	`/api/v1/templates/categories`	List categories
`GET`	`/api/v1/templates/stats`	Template usage statistics
`GET`	`/api/v1/templates/{id}`	Get one template
`POST`	`/api/v1/templates/{id}/apply`	Create a policy from a template

Base URL:

http://localhost:8081

The template routes are served by the Orchestrator directly (port 8081). Unlike /api/v1/dynamic-policies, they are not proxied through the Agent's single-entry-point router — call the Orchestrator (or whatever ingress fronts it in your deployment).

Authentication

The Orchestrator reads identity from headers set by the caller (or by an upstream gateway):

X-Tenant-ID — required for GET /api/v1/templates/stats and POST /api/v1/templates/{id}/apply; missing tenant context returns 401 with code UNAUTHORIZED. List, get, and categories do not require tenant context.
X-User-ID — recommended for apply requests; recorded as the created policy's created_by (defaults to system).

Errors use the shape {"error": {"code": "<STRING_CODE>", "message": "...", "details": [...]}} where details carries {field, message} entries on validation failures. If the Orchestrator has no database connection, all template endpoints return 503.

Listing Templates

Verified list query parameters:

Query param	Purpose
`category`	Filter by category
`search`	Search template names and descriptions
`tags`	Comma-separated tags
`active`	Filter active templates
`builtin`	Filter built-in templates
`page`	Page number
`page_size`	Page size, max `100`

Verified response wrapper:

{
  "templates": [],
  "pagination": {
    "page": 1,
    "page_size": 20,
    "total_items": 0,
    "total_pages": 0
  }
}

Single Template and Categories

GET /api/v1/templates/{id} returns a template wrapper around the full template object:

{
  "template": {
    "id": "tpl_general_rate_limiting",
    "name": "general_rate_limiting",
    "display_name": "Rate Limiting",
    "description": "Enforces rate limits per user/tenant to prevent abuse",
    "category": "general",
    "subcategory": "security",
    "template": {
      "name": "Rate Limiting",
      "type": "user",
      "conditions": [
        {
          "field": "user.request_count_1h",
          "operator": "greater_than",
          "value": "{{max_requests_per_hour}}"
        }
      ],
      "actions": [
        {
          "type": "block",
          "config": {
            "message": "Rate limit exceeded. Please try again later."
          }
        }
      ],
      "priority": 95
    },
    "variables": [
      {
        "name": "max_requests_per_hour",
        "default": 1000,
        "description": "Maximum requests per user per hour"
      }
    ],
    "is_builtin": true,
    "is_active": true,
    "version": "1.0",
    "tags": ["security", "rate_limiting", "abuse_prevention"],
    "created_at": "2025-01-01T00:00:00Z",
    "updated_at": "2025-01-01T00:00:00Z"
  }
}

Template variables support name, type, default, description, required, and validation (a regex the supplied value must match). {{variable}} placeholders in the template body are substituted at apply time.

Unknown template IDs return 404 with code NOT_FOUND.

GET /api/v1/templates/categories returns the distinct categories present in the deployment's template catalog:

{
  "categories": [
    "general",
    "compliance"
  ]
}

Usage Statistics

GET /api/v1/templates/stats returns per-template usage counts for the calling tenant (requires tenant context):

{
  "stats": [
    {
      "template_id": "tpl_general_rate_limiting",
      "template_name": "general_rate_limiting",
      "usage_count": 3,
      "last_used_at": "2026-07-01T09:00:00Z"
    }
  ]
}

Apply a Template

POST /api/v1/templates/{id}/apply is the fastest way to turn a reusable governance pattern into a tenant-owned policy.

Verified request fields:

Field	Notes
`variables`	Variable substitutions for the template. Variables marked `required` must be present; variables with a `validation` regex must match it
`policy_name`	Required — 3 to 100 characters
`description`	Optional — at most 500 characters
`enabled`	Boolean; defaults to `false` when omitted
`priority`	Optional; overrides the priority baked into the template

Example:

curl -X POST http://localhost:8081/api/v1/templates/tpl_general_rate_limiting/apply \
  -H "Content-Type: application/json" \
  -H "X-Tenant-ID: my-tenant" \
  -H "X-User-ID: [email protected]" \
  -d '{
    "variables": {
      "max_requests_per_hour": 500
    },
    "policy_name": "tenant-rate-limit",
    "enabled": true
  }'

Successful applies return 201 Created with success, the created policy (a dynamic policy resource owned by the calling tenant), usage_id, and message:

{
  "success": true,
  "policy": {
    "id": "550e8400-e29b-41d4-a716-446655440002",
    "name": "tenant-rate-limit",
    "type": "user",
    "conditions": [],
    "actions": [],
    "priority": 95,
    "enabled": true,
    "version": 1,
    "tenant_id": "my-tenant",
    "created_by": "[email protected]",
    "created_at": "2026-07-01T09:00:00Z",
    "updated_at": "2026-07-01T09:00:00Z"
  },
  "usage_id": "b2e5c1aa-2222-4333-8444-955556666777",
  "message": "Successfully created policy 'tenant-rate-limit' from template 'general_rate_limiting'"
}

Error cases: 400 VALIDATION_ERROR (policy name length, description length, missing required variables, variable pattern mismatch — with per-field details), 400 INVALID_JSON, 401 UNAUTHORIZED (no tenant context), 404 NOT_FOUND (unknown template), 500 INTERNAL_ERROR.

Why Teams Use This API

Security teams use templates to standardize AI guardrails across multiple tenants or applications.
Platform teams use templates to shorten onboarding for regulated use cases such as finance, healthcare, and regional deployments.
Engineers assessing AxonFlow get a practical bridge between community experimentation and more repeatable evaluation or enterprise rollout patterns.

Operational Readiness Checklist

Before relying on this page in a production rollout, pair it with the core operations docs:

Deployment Mode Matrix for self-hosted, Evaluation, Enterprise, SaaS, and In-VPC fit
Failure Modes And Recovery for degraded-provider, connector, approval, and runtime behavior
Capacity Planning for sizing and growth signals
Community vs Evaluation vs Enterprise for limits, support surfaces, and upgrade triggers

Overview​

Authentication​

Listing Templates​

Single Template and Categories​

Usage Statistics​

Apply a Template​

Why Teams Use This API​

Related Docs​

Operational Readiness Checklist​