Primary navigation

Legacy APIs

Manage permissions in the OpenAI platform

Use role-based access control (RBAC) to manage permissions across your organization and projects.

Role-based access control (RBAC) lets you decide who can do what across your organization and projects—both through the API and in the Dashboard. The same permissions govern both surfaces: if someone can call an endpoint (for example, /v1/chat/completions), they can use the equivalent Dashboard page, and missing permissions disable related UI (such as the Upload button in Playground). With RBAC you can:

  • Group users and assign permissions at scale
  • Create custom roles with the exact permissions you need
  • Scope access at the organization or project level
  • Enforce consistent permissions in both the Dashboard and API

Key concepts

  • Organization: Your top-level account. Organization roles can grant access across all projects.
  • Project: A workspace for keys, files, and resources. Project roles grant access within only that project.
  • Groups: Collections of users you can assign roles to. Groups can be synced from your identity provider (via SCIM) to keep membership up to date automatically.
  • Roles: Bundles of permissions (like Models Request or Files Write). Roles can be created for the organization under Organization settings, or created for a specific project under that project’s settings. Once created, organization or project roles can be assigned to users or groups. Users can have multiple roles, and their access is the union of those roles.
  • Permissions: The specific actions a role allows (e.g., make request to models, read files, write files, manage keys).

Permissions

The table below shows the available permissions, which preset roles include them, and whether they can be configured for custom roles.

AreaWhat it allowsOrg owner permissionsOrg reader permissionsProject owner permissionsProject member permissionsProject viewer permissionsCustom role eligible
List modelsList models this organization has access toReadReadReadReadRead
GroupsView and manage groupsRead, WriteReadRead, WriteRead, WriteRead
RolesView and manage rolesRead, WriteReadRead, WriteRead, WriteRead
Organization AdminManage organization users, projects, invites, admin API keys, and rate limitsRead, Write
UsageView usage dashboard and exportRead
External KeysView and manage keys for Enterprise Key ManagementRead, Write
IP allowlistView and manage IP allowlistRead, Write
mTLSView and manage mutual TLS settingsRead, Write
OIDCView and manage OIDC configurationRead, Write
Model capabilitiesMake requests to chat completions, audio, embeddings, and imagesRequestRequestRequestRequest
AssistantsCreate and retrieve AssistantsRead, WriteRead, WriteRead, WriteRead, WriteRead
ThreadsCreate and retrieve Threads/Messages/RunsRead, WriteRead, WriteRead, WriteRead, WriteRead
EvalsCreate, retrieve, and delete EvalsRead, WriteRead, WriteRead, WriteRead, WriteRead
Fine-tuningCreate and retrieve fine tuning jobsRead, WriteRead, WriteRead, WriteRead, WriteRead
FilesCreate and retrieve filesRead, WriteRead, WriteRead, WriteRead, WriteRead
Vector StoresCreate and retrieve vector storesRead, WriteRead, WriteRead, WriteRead, Write
Responses APICreate responsesRead, WriteRead, WriteRead, WriteRead, Write
PromptsCreate and retrieve prompts to use as context for Responses API and Realtime APIRead, WriteRead, WriteRead, WriteRead, WriteRead
WebhooksCreate and view webhooks in your projectRead, WriteReadRead, WriteRead, WriteRead
DatasetsCreate and retrieve DatasetsRead, WriteRead, WriteRead, WriteRead, WriteRead
Project API KeysPermission for a user to manage their own API keysRead, WriteRead, WriteRead, WriteRead, WriteRead
Project AdministrationManage project users, service accounts, API keys, and rate limits via management APIRead, WriteRead, Write
BatchCreate and manage batch jobsRead, WriteRead, WriteRead, WriteRead, WriteRead
Service AccountsView and manage project service accountsRead, WriteRead, Write
VideosCreate and retrieve videosRead, WriteRead, WriteRead, WriteRead, Write
VoicesCreate and retrieve voicesRead, WriteRead, WriteRead, WriteRead, WriteRead
Agent BuilderCreate and manage agents and workflows in Agent BuilderRead, WriteReadRead, WriteRead, WriteRead

Setting up RBAC

Allow up to 30 minutes for role changes and group sync to propagate.

  1. Create groups Add groups for teams (e.g., “Data Science”, “Support”). If you use an IdP, enable SCIM sync so group membership stays current.

  2. Create custom roles Start from least privilege. For example:

    • Model Tester: Models Read, Model Capabilities Request, Evals
    • Model Engineer: Model Capabilities Request, Files Read/Write, Fine-tuning
  3. Assign roles

    • Organization level roles apply everywhere (all projects within the organization).
    • Project level roles apply only in that project. You can assign roles to users and groups. Users can hold multiple roles; access is the union.
  4. Verify Use a non-owner account to confirm expected access (API and Dashboard). Adjust roles if users can see more than they need.

Use the principle of least privilege. Start with the minimum permissions required for a task, then add more only as needed.

Access configuration examples

Small team

  • Give the core team an org-level role with Model Capabilities Request and Files Read/Write.
  • Create a project for each app; add contractors to those projects only, with project-level roles.

Larger org

  • Sync groups from your IdP (e.g., “Research”, “Support”, “Finance”).
  • Create custom roles per function and assign at the org level; or only grant project-specific roles when a project needs tighter controls.

Contractors & vendors

  • Create a “Contractors” group without org-level roles.
  • Add them to specific projects with narrowly scoped project roles (for example, read-only access).

How user access is evaluated

In the dashboard, we combine:

  • roles from the organization (direct + via groups)
  • roles from the project (direct + via groups)

The effective permissions are the union of all assigned roles.

If requesting with an API key within a project, we take the permissions assigned to the API key, and ensure that the user has some project role that grants them those permissions. For example, if requesting /v1/models, the API key must have api.model.read assigned to it and the user must have a project role with api.model.read.

Best practices

  • Model your org in groups: Mirror teams in your IdP and assign roles to groups, not individuals.
  • Separate duties: reading models vs. uploading files vs. managing keys.
  • Project boundaries: put experiments, staging, and production in separate projects.
  • Review regularly: remove unused roles and keys; rotate sensitive keys.
  • Test as a non-owner: validate access matches expectations before broad rollout.