Enable or disable a model access provider with the Organization API

Toggle a catalog provider on or off for one linked team with PUT https://api.cursor.com/organizations/teams/{teamId}/model-access/providers/{provider}, or for many linked teams with PUT https://api.cursor.com/organizations/teams/model-access/providers/{provider}. Official reference: Organization API → Model access. These routes are in preview and may change before general availability.

Authenticate with an Organization API key (Basic auth, key as username, empty password). Writes need models:* (or admin:*). Rate limit: 20 requests per minute. Writes appear in team audit logs as team_settings events. Enterprise organizations; target teams must have model access control available.

Single-team writes return 409 when the team is still unrestricted or legacy. Create a custom policy first: Set model access configuration with the Organization API. Discover catalog provider ids with List model access providers. Path segments are catalog ids such as openai or anthropic.

Update one linked team

curl -X PUT https://api.cursor.com/organizations/teams/7/model-access/providers/openai \
  -u YOUR_ORGANIZATION_API_KEY: \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

Path / body	Rules
teamId	Integer ID of a team linked to the organization
provider	Required catalog provider id (for example openai or anthropic)
enabled	Required boolean

Unknown or unlinked teamId returns 404. Teams without model access control available return 403.

Disabling a provider blocks its models for the team baseline. Organization Groups can still widen access for some members; group allowlists are outside this API.

Confirm with a providers GET

curl -X GET https://api.cursor.com/organizations/teams/7/model-access/providers \
  -u YOUR_ORGANIZATION_API_KEY:

Look for the matching providers[].id and its enabled value. Per-model toggles and parameter maps use a separate route: Set model access and parameters.

Bulk update many linked teams

Up to 100 teamIds per request. HTTP 200 means the batch was processed, not that every row succeeded — inspect errorCount and each results[].status. Successful rows are not rolled back. Operations are idempotent per team, so retry only failed teamIds. A 4xx or 5xx rejects the whole request and applies no changes.

curl -X PUT https://api.cursor.com/organizations/teams/model-access/providers/openai \
  -u YOUR_ORGANIZATION_API_KEY: \
  -H "Content-Type: application/json" \
  -d '{
    "teamIds": [7, 8, 9],
    "enabled": false
  }'

Example response:

{
  "results": [
    { "teamId": 7, "status": "success" },
    { "teamId": 8, "status": "success" },
    {
      "teamId": 9,
      "status": "error",
      "errorMessage": "Team has no model access policy. Create one with PUT /teams/model-access/configuration, or enable model access in Team Settings → Models."
    }
  ],
  "successCount": 2,
  "errorCount": 1
}

In that example HTTP status is still 200 because the batch completed. Teams 7 and 8 keep the provider disabled; retry team 9 only after creating its configuration.

Pitfalls

• Calling the single-team route while state is unrestricted or legacy — expect 409 until configuration seeds a custom policy.
• Treating bulk HTTP 200 as all-success — always read errorCount and per-row status.
• Putting a display name in the path (OpenAI) fails; the path needs the catalog id (openai).
• Expecting a provider PUT to rewrite per-model parameter restrictions — this route only sets enabled on the provider.
• Calling with members:* or usage:* alone — model-access writes need models:* or admin:*.

For the single-team Admin API counterpart, see Enable or disable a model access provider with the Admin API.