Access Grants
Access grants are per-domain delegation with optional record-level restrictions. Use them when role assignments are too coarse — you want to give a specific team access to a specific zone, limited to certain record types or name patterns, optionally for a bounded time.
Base path: /api/v1/domains/{domain_id}/access-grants
Required permission: access_grants:* on the domain (typically domain admin or tenant admin)
When to use grants vs role assignments#
| Situation | Use |
|---|---|
| Team always has full control of the tenant | Tenant admin role |
| Team always has full control of one zone | Domain admin role (scoped to the zone) |
| Contractor needs access to one zone for Q4 only | Access grant with expires_at |
Team should only edit *.dev. records |
Access grant with record_pattern |
Service only needs to manipulate A and AAAA |
Access grant with record_types |
Access grants are additive to role assignments — a user with no tenant role can still manage a domain they have a grant on.
Shape#
An access grant consists of:
- Grant type.
userorgroup. - Grantee ID. The user or group receiving access.
- Role. What level of access they get on this domain (domain_manager, record_editor, read_only, or a custom role).
- Record pattern. Optional. Glob-style pattern on record name (
*.dev,api.*). - Record types. Optional. List of types the grant applies to (
["A", "AAAA", "CNAME"]). - Expires at. Optional. Grant auto-expires at this timestamp.
- Notes. Free-form.
List grants#
1 2 | |
Query parameters:
| Param | Type | Notes |
|---|---|---|
include_expired |
boolean | Include grants past their expires_at |
Response:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | |
Create a grant#
1 2 3 4 5 6 7 8 9 10 11 12 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | |
Get, update, delete#
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
How patterns match#
Record patterns are glob-style. Only * is supported (no ? or character classes):
| Pattern | Matches |
|---|---|
* |
Anything |
*.staging |
foo.staging, bar.staging.x, not staging alone |
api.* |
api.foo, api.bar.baz, not api alone |
web* |
web, web1, website, webapi.foo |
example.com |
Exact match |
Patterns match against the record name as ScaiDNS stores it (typically the relative form — www for www.example.com).
How record types filter#
If record_types is present, the grant only applies when the caller is mutating those types. Reading remains unrestricted (read access is either granted or not — you can't have read-only-A).
Empty or omitted record_types means all types.
Grant precedence#
When a user has multiple paths to a permission:
- Platform admin always wins.
- Tenant admin wins for their tenant.
- Role assignments scoped to a domain (including grants) are merged.
- If any grant matches, access is allowed. If none match, access is denied.
Grants are strictly additive. A grant can't reduce someone's existing permissions — if they're already a tenant admin, a restrictive grant doesn't limit them.
Groups#
Grants can target groups. All members of the group inherit the grant.
1 2 3 4 5 | |
When a user is added to the group, the grant applies to them. When removed, it no longer does.
Expiry#
Grants with expires_at in the past are ignored when computing permissions. They're not automatically deleted — use GET /access-grants/?include_expired=false (the default) to hide them, or clean them up periodically.
Audit#
Every grant creation, update, and revocation goes to the audit log with action access_grant.*. See Audit Log.
Patterns#
"Contractor access until end of engagement"#
1 2 3 4 5 6 7 | |
"Team can only manage dev subdomains"#
1 2 3 4 5 6 7 | |
"Service manipulates only A records for load balancing"#
1 2 3 4 5 6 7 8 | |
Errors#
| Status | Meaning |
|---|---|
400 |
Invalid pattern, unknown record type, malformed expiry |
403 |
Caller can't manage grants on this domain |
404 |
Grant, grantee, or role not found |
409 |
Duplicate grant (same grantee + role already exists) |
422 |
Trying to grant a role with permissions the caller doesn't have |
Related#
- Permissions and Access — how authorization resolves.
- Users, Groups, and Roles — role assignment reference.