# Update Rule Set Proxy

`PUT /api/2.0/preview/accounts/access-control/rule-sets`

Replace the rules of a rule set. First, use get to read the current version of the rule set before modifying it.
 This pattern helps prevent conflicts between concurrent updates.

API scopes: access-management

## Request body

- `account_id` (string, optional)
  <Databricks> account ID.
- `name` (string, optional)
  Name of the rule set.
- `rule_set` (object, optional)
  - `name` (string, optional)
    Name of the rule set.
  - `etag` (string, optional)
    Identifies the version of the rule set returned.
     Etag used for versioning. The response is at least as fresh as the eTag provided.
     Etag is used for optimistic concurrency control as a way to help prevent simultaneous
     updates of a rule set from overwriting each other. It is strongly suggested that systems
     make use of the etag in the read -> modify -> write pattern to perform rule set updates in
     order to avoid race conditions that is get an etag from a GET rule set request, and pass it
     with the PUT update request to identify the rule set version you are updating.
  - `grant_rules` (array of object, optional)
    - `principals` (array of string, optional)
      Principals this grant rule applies to.
       A principal can be a user (for end users), a service principal (for applications and
       compute workloads), or an account group. Each principal has its own identifier format:
       * users/<USERNAME>
       * groups/<GROUP_NAME>
       * servicePrincipals/<SERVICE_PRINCIPAL_APPLICATION_ID>
    - `role` (string, optional)
      Role that is assigned to the list of principals.

## Returns

- `name` (string, optional)
  Name of the rule set.
- `etag` (string, optional)
  Identifies the version of the rule set returned.
   Etag used for versioning. The response is at least as fresh as the eTag provided.
   Etag is used for optimistic concurrency control as a way to help prevent simultaneous
   updates of a rule set from overwriting each other. It is strongly suggested that systems
   make use of the etag in the read -> modify -> write pattern to perform rule set updates in
   order to avoid race conditions that is get an etag from a GET rule set request, and pass it
   with the PUT update request to identify the rule set version you are updating.
- `grant_rules` (array of object, optional)
  - `principals` (array of string, optional)
    Principals this grant rule applies to.
     A principal can be a user (for end users), a service principal (for applications and
     compute workloads), or an account group. Each principal has its own identifier format:
     * users/<USERNAME>
     * groups/<GROUP_NAME>
     * servicePrincipals/<SERVICE_PRINCIPAL_APPLICATION_ID>
  - `role` (string, optional)
    Role that is assigned to the list of principals.

## Response

```json
{
  "etag": "ENCODED_VERSION_TOKEN",
  "grant_rules": [
    {
      "principals": [
        "users/some-user@company.com",
        "groups/researchers"
      ],
      "role": "roles/servicePrincipal.user"
    }
  ],
  "name": "accounts/<ACCOUNT_ID>/servicePrincipals/<SERVICE_PRINCIPAL_APPLICATION_ID>/ruleSets/default"
}
```