Authaz logoAuthaz
DocumentationAPI Reference
  • Get Started

    • Authaz
    • Core Concepts
    • Set up your app
    • Quickstart — cURL
  • Authentication

    • Authentication Settings
    • Signup
    • Invitations
    • Password Authentication
    • Multi-Factor Auth
    • Magic Link
    • OAuth / Social Login
    • Passkey (WebAuthn)
    • SAML SSO
    • Machine-to-Machine (M2M)
    • API Keys
  • Authorization

    • Authorization
    • Resources
    • Policies
    • Roles
    • Access Explorer
  • Tenancy

    • Multi-tenancy
    • Tenancy Customization
  • Brand & Host

    • Branding
    • Custom Domains
    • Communications & Email Templates
  • Operate

    • Users
    • Analytics
    • Audit Logs
    • Application Settings
  • SDK Quickstarts

    • Quickstart — Next.js
    • Quickstart — React SPA
    • Quickstart — Hono
    • Quickstart — .NET (Authaz.Sdk)
  • Recipes

    • Recipes & Cookbook
    • Next.js — first integration
    • Next.js — B2B SaaS (multi-tenant)
    • Hono — first integration
    • Hono — B2B SaaS (multi-tenant)
    • React SPA — first integration
    • React SPA — B2B SaaS (multi-tenant)
    • .NET — first integration
    • .NET — B2B SaaS (multi-tenant)
  • Reference

    • Tokens
    • API Reference
    • Errors & Troubleshooting
  • Documentation

    • How Authaz is Built
  1. Authaz
  2. Docs
  3. Authorization
  4. Policies

Authorization

Policies

3 min read·Updated Jun 19, 2026

The Policies page (under Authorization → Manage) holds reusable bundles of permissions. Roles attach policies to compose effective access — and the same policy can attach to many roles, so editing it once updates every role that uses it.

# Create a policy
curl -X POST https://your-app.authaz.io/api/v1/applications/{appId}/policies \
  -H "X-API-Key: $AUTHAZ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Invoices Writer",
    "description": "Create, read, update, and send invoices.",
    "permissions": [
      "invoices:create",
      "invoices:read",
      "invoices:update",
      "invoices:send"
    ]
  }'

The dashboard lists every policy with its name, description, permission count, and the number of roles it's attached to.

What's in a policy#

  • name and description — what shows up in the role editor when you're picking what to attach.
Previous
Resources
Next
Roles
  • permissions — a list of resource:action strings, drawn from the Resource Catalog. Authaz rejects permissions that don't exist in the catalog.
  • tenantId (optional) — for tenant-scoped policies. Most policies are application-wide; tenant scoping is rarely needed at the policy level since roles already carry that scope.
  • A policy with zero permissions is valid — useful as a placeholder while you're modelling — but won't grant anything until you populate it.

    Why policies (vs putting permissions on roles directly)#

    Three reasons:

    1. Reuse. Invoices Writer ends up on Member, Admin, and Owner. Defining the permission list once means the three roles can never drift out of sync.
    2. Refactoring. Add invoices:archive to the policy; every attached role picks it up automatically.
    3. Auditability. "What does Member do?" is answerable in one click — read the policies attached. No flat permission lists to compare.

    If you only have two or three roles and never refactor, you could put permissions directly in the role. Authaz lets you, but most teams reach for policies within a few weeks.

    Editing a policy#

    Authorization → Policies → click a policy opens the editor:

    • Permissions — add or remove. The editor shows which resource:action pairs exist in the catalog and prevents you from typing one that doesn't.
    • Attached to — every role currently using this policy. Removing a permission here removes it from all those roles instantly.
    • Activity — recent edits from the audit log.

    Composing roles from policies#

    The role editor (see Roles) pulls from this same policy list. The typical workflow:

    1. Sketch the policies you need: one per coherent capability set (invoices_writer, customer_admin, billing_owner, reports_viewer).
    2. Build roles by attaching policies — Member = invoices_writer + reports_viewer, Admin = invoices_writer + customer_admin + reports_viewer.
    3. Use Access Explorer to verify a few representative users get exactly what you intended.

    When you discover you need a new capability, the question is "should this go in an existing policy, or is it its own thing?" If it's part of a coherent set already represented (e.g. archiving invoices belongs in invoices_writer), add it there. Otherwise create a new policy and attach it to the roles that should have it.

    Listing and querying#

    # List
    curl https://your-app.authaz.io/api/v1/applications/{appId}/policies \
      -H "X-API-Key: $AUTHAZ_API_KEY"
     
    # Get one
    curl https://your-app.authaz.io/api/v1/applications/{appId}/policies/{policyId} \
      -H "X-API-Key: $AUTHAZ_API_KEY"
     
    # Which roles use this policy?
    curl https://your-app.authaz.io/api/v1/applications/{appId}/policies/{policyId}/roles \
      -H "X-API-Key: $AUTHAZ_API_KEY"

    Updating#

    # Replace the permissions list
    curl -X PATCH https://your-app.authaz.io/api/v1/applications/{appId}/policies/{policyId} \
      -H "X-API-Key: $AUTHAZ_API_KEY" \
      -H "Content-Type: application/json" \
      -d '{
        "permissions": [
          "invoices:create",
          "invoices:read",
          "invoices:update",
          "invoices:send",
          "invoices:archive"
        ]
      }'

    Adding a permission propagates instantly to every role that has the policy attached. Removing a permission revokes it from those roles' assignees on the next permission check.

    Deleting#

    curl -X DELETE https://your-app.authaz.io/api/v1/applications/{appId}/policies/{policyId} \
      -H "X-API-Key: $AUTHAZ_API_KEY"

    Authaz blocks the delete if the policy is still attached to any roles — detach it from those roles first, or pass force=true (which removes both the policy and its attachments, recorded as a single audit-log event).

    A note on naming#

    Policy names show up in the role editor and in the audit log. Keep them short and capability-focused — Invoices Writer, Customer Admin, Billing Owner. Avoid role-shaped names like Member or Admin; those are roles' job.

    Next steps#

    • Roles — attach policies to roles and assign them.
    • Resources — the catalog the permissions in your policies draw from.
    • Access Explorer — verify your composition produces the access you intended.