---
title: "Setorgpolicy"
method: PUT
path: "/v1/b2b/rbac/organizations/{organization_id}"
tags: ["B2B Rbac"]
---

# Setorgpolicy

`PUT /v1/b2b/rbac/organizations/{organization_id}`

## Request

- Base URL: `https://api.stytch.com`
- URL: `https://api.stytch.com/v1/b2b/rbac/organizations/{organization_id}`
- Auth: HTTP basic

The organization RBAC policy feature is currently in private beta and must be enabled for your Workspace. Please contact Stytch support at support@stytch.com to request access.

Set the RBAC Policy for a specific Organization within your Stytch Project. An Organization RBAC Policy allows you to define roles that are specific to that organization, providing fine-grained control over permissions at the organization level.

This endpoint allows you to create, update, or replace the organization-scoped roles for a given organization. Organization policies supplement the project-level RBAC policy with additional roles that are only applicable within the context of that specific organization.

The organization policy consists of roles, where each role defines:
- A unique `role_id` to identify the role
- A human-readable `description` of the role's purpose
- A set of `permissions` that specify which actions can be performed on which resources

When you set an organization policy, it will replace any existing organization-specific roles for that organization. The project-level RBAC policy remains unchanged.

Organization-specific roles are useful for scenarios where different organizations within your project require different permission structures, such as:
- Multi-tenant applications with varying access levels per tenant
- Organizations with custom approval workflows
- Different organizational hierarchies requiring unique role definitions

Check out the [RBAC overview](https://stytch.com/docs/b2b/guides/rbac/overview) to learn more about Stytch's RBAC permissioning model and organization-scoped policies.

## Path parameters

- `organization_id` string, required: Globally unique UUID that identifies a specific Organization. The `organization_id` is critical to perform operations on an Organization, so be sure to preserve this value. You may also use the organization_slug or organization_external_id here as a convenience.

## Request body

- ApiB2bRbacV1B2bRbacOrganizationsSetOrgPolicyRequest: Request type
  - `org_policy` ApiB2bRbacV1OrgPolicy, required
    - `roles` ApiB2bRbacV1PolicyRole[], required: An array of [Role objects](https://stytch.com/docs/b2b/api/rbac-role-object).
      - `role_id` string, required: The unique identifier of the RBAC Role, provided by the developer and intended to be human-readable. Reserved `role_id`s that are predefined by Stytch include: * `stytch_member` * `stytch_admin` Check out the [guide on Stytch default Roles](https://stytch.com/docs/b2b/guides/rbac/stytch-default) for a more detailed explanation.
      - `description` string, required: The description of the RBAC Role.
      - `permissions` ApiB2bRbacV1PolicyRolePermission[], required: A list of permissions that link a [Resource](https://stytch.com/docs/b2b/api/rbac-resource-object) to a list of actions.
        - `resource_id` string, required: A unique identifier of the RBAC Resource, provided by the developer and intended to be human-readable. A `resource_id` is not allowed to start with `stytch`, which is a special prefix used for Stytch default Resources with reserved `resource_id`s. These include: * `stytch.organization` * `stytch.member` * `stytch.sso` * `stytch.self` Check out the [guide on Stytch default Resources](https://stytch.com/docs/b2b/guides/rbac/stytch-default) for a more detailed explanation.
        - `actions` string[], required: A list of permitted actions the Scope is required to take with the provided Resource. You can use `*` as a wildcard to require a Scope permission to use all possible actions related to the Resource.

## Response `200`

Successful response

- ApiB2bRbacV1B2bRbacOrganizationsSetOrgPolicyResponse
  - `request_id` string, required: Globally unique UUID that is returned with every API call. This value is important to log for debugging purposes; we may ask for this value to help identify a specific API call when helping you debug an issue.
  - `org_policy` ApiB2bRbacV1OrgPolicy, required
    - `roles` ApiB2bRbacV1PolicyRole[], required: An array of [Role objects](https://stytch.com/docs/b2b/api/rbac-role-object).
      - `role_id` string, required: The unique identifier of the RBAC Role, provided by the developer and intended to be human-readable. Reserved `role_id`s that are predefined by Stytch include: * `stytch_member` * `stytch_admin` Check out the [guide on Stytch default Roles](https://stytch.com/docs/b2b/guides/rbac/stytch-default) for a more detailed explanation.
      - `description` string, required: The description of the RBAC Role.
      - `permissions` ApiB2bRbacV1PolicyRolePermission[], required: A list of permissions that link a [Resource](https://stytch.com/docs/b2b/api/rbac-resource-object) to a list of actions.
        - `resource_id` string, required: A unique identifier of the RBAC Resource, provided by the developer and intended to be human-readable. A `resource_id` is not allowed to start with `stytch`, which is a special prefix used for Stytch default Resources with reserved `resource_id`s. These include: * `stytch.organization` * `stytch.member` * `stytch.sso` * `stytch.self` Check out the [guide on Stytch default Resources](https://stytch.com/docs/b2b/guides/rbac/stytch-default) for a more detailed explanation.
        - `actions` string[], required: A list of permitted actions the Scope is required to take with the provided Resource. You can use `*` as a wildcard to require a Scope permission to use all possible actions related to the Resource.
  - `status_code` integer, required: The HTTP status code of the response. Stytch follows standard HTTP response status code patterns, e.g. 2XX values equate to success, 3XX values are redirects, 4XX are client errors, and 5XX are server errors.

## Other responses

- `400`: Bad request
- `401`: Unauthorized
- `429`: Too Many Requests
- `500`: Internal server error

## Changes

- **2026-03-07** `110f26a94e5b`: 1 info
  - endpoint added
- **2026-03-06** `9cab20b8eca7`: 1 breaking
  - api path removed without deprecation
- **2026-01-21** `3e4c16dac486`: 1 breaking, 1 info
  - the request property `org_policy` became required
  - the response property `org_policy` became required for the status `200`
- **2026-01-09** `7dfcc14e566c`: 1 info
  - endpoint added

[Operation history](https://skmtc.dev/stytch/apis/stytch-api/changes/v1/b2b/rbac/organizations/:organization_id/put.md)

---

[API](https://skmtc.dev/stytch/apis/stytch-api.md) - [All operations](https://skmtc.dev/stytch/apis/stytch-api/llms.txt) - [OpenAPI document](https://skmtc.dev/stytch/apis/stytch-api/revisions/6d1ff7474803?raw)