---
search:
  tags:
    - Views
    - PUT
seo:
  description: >-
    Grant or revoke access to a View. Reference for the PUT
    /v1/views/id/{view_id}/access endpoint in the Roboto REST API.
sidebar:
  label: Edit view access
  badge: PUT
title: Edit view access
type: openapi-operation
---
Grant or revoke access to a View.

Adding and removing are authorized separately, following ``edit_collection_access``: a
request doing both must satisfy both, and one doing neither is a no-op that needs
neither.

Unlike ``edit_collection_access``, the gate also depends on *which* relation is being
changed. ``associated_group`` is not an ordinary grant — the org's all-members group
carries ``can_view_views``, so adding or removing it is what makes a View org-visible or
private, and that is reserved to the author. Every other editable relation stays on
``can_add_access`` / ``can_remove_access``, which is what lets an editor hand out access,
edit rights included, without also controlling who can see the View.

Gating the whole call on ``can_change_accessibility`` would not work: one request may mix
an ordinary grant with a sharing change, and an editor has to keep being able to make the
former. So the two are checked independently and a request needs whichever apply to it.

Authorizing here rather than in the service means a request that fails any of these checks
writes nothing. ``generic_edit_access`` applies its adds before it validates the removes,
so a partially-authorized request must not reach it.

### Access control
 - Restricted tokens need the API scope `api.everything_else`

`PUT /v1/views/id/{view_id}/access`