Restrictions

Create a restriction

Creates a restriction. Requires restriction:manage and the restrictions plan feature; a user target additionally requires restriction:override. A member is bound by their role's rules and their own at once, so a member's allow or block rule only ever narrows. mode: "except" is 400: the one way to loosen a role rule for one member is an approved access grant (POST /access-request/{id}/resolve), which records who asked, who approved it and, optionally, when it expires. A rule aimed at yourself is always 403, even when nothing restricts you. Changes take effect within about a minute.

A connector named in connector_slugs must not also appear as a tools[].connector_slug: 400, naming the connector. Restricting a whole connector already settles every tool on it, so the tool entries change nothing; on an allow rule they are worse than nothing, because the rule then grants the whole connector rather than the tools that were picked. Read summary back to see what the rule you just wrote does.

post/restriction

Request

  • Base URL: https://api.elaichi.ai
  • URL: https://api.elaichi.ai/restriction
  • Auth: HTTP bearer

Headers

X-Organization-Idstring

Target organization (org_…). Required for cookie/session auth on org-scoped routes; optional for API tokens, which carry their organization, and rejected when it names a different one.

Request body

target_type'role' | 'user' required
target_idstring required

Role id (role_…) or user id (usr_…).

mode'allow' | 'block' required
connector_slugsstring[]

Whole connectors the rule covers. Defaults to empty — which on an allow rule with no tools either means the rule blocks EVERY connector and tool for its target, not that it allows them all. The allowlist engages on mode, not on what the rule names.

Response

Created

idstring

Restriction id (rstr_…).

target_type'role' | 'user'

Whether this rule applies to everyone holding a role, or to one specific member.

target_idstring

Role id (role_…) or user id (usr_…), matching target_type.

mode'allow' | 'block'

allow makes the listed connectors and tools the ONLY ones the target may use; block removes exactly the listed ones and leaves everything else reachable. The allowlist engages on the MODE, not on what the rule names: an allow rule with empty connector_slugs and empty tools blocks every connector and every tool for its target. A member is bound by their role's rules and their own allow/block rules at once; a connector or tool is reachable only when both admit it. except no longer appears here: the way to lift a role rule for one member is an approved access grant (POST /access-request/{id}/resolve), not a rule you write or read through this endpoint.

connector_slugsstring[]

Whole connectors covered by the rule. A slug here settles every tool on that connector, so it must not also appear as a tools[].connector_slug.

summarystring

One plain sentence saying what this rule does ("Allows botify, plus 2 tools in slack. Everything else is blocked."), so every client says the same thing. Read-only, derived from mode, connector_slugs and tools, never stored. It describes what is enforced: tool entries on a connector already named whole are inert, so they do not appear in it. Connectors are named by slug. Show this rather than composing your own.

created_bystring nullable

User id (usr_…) of the author.

created_by_labelstring nullable

Display name (or email) of the author. null while created_by is a real id means the author has left the org; show it as "Former member", the same word GET /audit-log's actor summary uses. Also null when created_by itself is.

updated_bystring nullable

User id (usr_…) of whoever wrote the row LAST — the author until somebody else edits it. Null only on a row written before this field existed; the self-target rule reads that as "not you", so such a row constrains its author like anyone else's.

updated_by_labelstring nullable

Display name (or email) for updated_by, with the same "Former member" meaning for a null beside a real id. To decide whether somebody other than the author last wrote the row, compare the two ids, never the two labels: two people can share a display name, and both labels are null once both have left.

legacy_overrideboolean

True on a member row that still REPLACES its member's role rules — the meaning every member row had before role and member rules combined, kept on the rows whose conversion could not be proven to leave the member's access unchanged (a role allowlist beside member rows with none). While any of a member's rows carries it, no role rule reaches them, including ones added later. Read-only except that PATCH may send false to clear it on all of that member's rows, which only ever narrows them.

created_atstring date-time
updated_atstring date-time
target_labelstring nullable

Display name (or email) of a user target. Always null on a role target (look the role up by target_id in GET /role), and null on a stale target whose member has been deleted.

connector_labelsobject

Slug to catalog display name for the first 8 connectors the rule enforces (whole connectors first, then tool-only ones), enough for a row's badges and hover text. A slug the catalog could not name (deleted, or the catalog unreachable) is absent: fall back to the slug.

scope_connectorsobject

One-row responses only (GET /restriction/{id}, POST /restriction, PATCH /restriction/{id}; never a list row): label and logo for every connector the rule scopes (its whole connectors and the connectors its tools belong to), keyed by slug. At most 1000 connectors plus the connectors of 1000 tools. A slug the catalog cannot resolve reads its slug as label and a null logo.

can_manageboolean

Whether the caller may create, edit or delete this row: restriction:manage, plus two extra checks the write routes enforce. A user-targeted row additionally needs restriction:override, and a row targeting the caller (or a role whose permission set equals theirs exactly) is refused so nobody can free themselves from a restriction. A row showing can_manage: true will not 403 on write. Read routes need only restriction:view, so this is false for a viewer.

Changes

No recorded changes to this operation across all 1 revision of this API.