Limit members to their projects

By default every member of an organisation sees every project. With per-project access on, owners and admins still see every project, and each member sees only the projects they've been granted. Any other project answers 404, as if it doesn't exist.

You need to be the organisation's owner to turn it on or off, and an owner or admin to grant projects. Not every cloud offers per-project access: where it doesn't, the organisation's per_project_access is always false.

The examples use the variables set in Make your first calls: BASE, BREQWATR_API_KEY and ORG_ID.

1. Turn it on

curl -s -X PATCH "$BASE/orgs/$ORG_ID" \
  -H "Authorization: Bearer $BREQWATR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"per_project_access": true}' | jq

{
  "data": {
    "id": "3f1a6c52-8d4e-4b0f-9a77-2e5c1d90b8a4",
    "name": "Acme",
    "slug": "acme",
    "status": "active",
    "role": "owner",
    "per_project_access": true,
    "created_at": "2026-09-14T15:04:05Z"
  }
}

Turning it on grants every member every existing project, so nobody loses access at that moment. Nothing changes for members until you narrow their access in step 3.

Anyone but the owner gets 403 owner_required. On a cloud that doesn't offer per-project access, the request answers 409 per_project_access_unavailable.

2. See who can reach what

curl -s "$BASE/orgs/$ORG_ID/members" -H "Authorization: Bearer $BREQWATR_API_KEY" | jq

{
  "data": [
    {
      "id": "7b2d9e41-3c58-4a6f-b0d2-8e1f5a9c3d70",
      "name": "Alex Chen",
      "email": "alex@example.com",
      "role": "owner",
      "joined_at": "2026-09-14T15:04:05Z",
      "project_access": "all"
    },
    {
      "id": "c41e8b07-2fd6-49a3-b1e8-5d06a7c3f912",
      "name": "Sam Lee",
      "email": "sam@example.com",
      "role": "member",
      "joined_at": "2026-09-15T09:30:00Z",
      "project_access": {
        "project_ids": [
          "a9d27e10-64b3-4f18-8c05-71e3f6ab20d9",
          "e5f80c2b-917a-4d36-a4b1-0c6d2e8f7a15"
        ]
      }
    }
  ],
  "next_cursor": null
}

Owners and admins read "all". For a member, you see the ids of the projects they can reach. A member reading the list sees only a count, as granted and total.

3. Narrow a member's access

Send the member's id from step 2, which is their membership id, with the projects they should keep:

export MEMBER_ID=c41e8b07-2fd6-49a3-b1e8-5d06a7c3f912
curl -s -X PATCH "$BASE/orgs/$ORG_ID/members/$MEMBER_ID" \
  -H "Authorization: Bearer $BREQWATR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"project_ids": ["a9d27e10-64b3-4f18-8c05-71e3f6ab20d9"]}' | jq

project_ids replaces the member's whole set, so list every project they should see, not just the ones to add. An empty list leaves them with none.

A few things are refused:

Request	Response
An id that isn't a project of this organisation	400 invalid_parameter
An owner or admin's membership; they always see every project	409 not_member_role
Your own membership	409 own_membership
While per-project access is off	409 per_project_access_off

Projects created after you turn per-project access on aren't granted to anyone. Owners and admins see them straight away; add them to a member's project_ids when that member needs them.

4. Invite someone to specific projects

While per-project access is on, an invitation can say which projects a new member gets:

curl -s -X POST "$BASE/orgs/$ORG_ID/invitations" \
  -H "Authorization: Bearer $BREQWATR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen)" \
  -d '{"email": "new@example.com", "role": "member", "project_ids": ["a9d27e10-64b3-4f18-8c05-71e3f6ab20d9"]}' | jq

They can reach those projects once they accept. Sending project_ids while per-project access is off answers 400 invalid_parameter.

Turning it off

Send {"per_project_access": false} to the same address as step 1. Every member sees every project again.

Turning it back on later grants every member every project again, as in step 1, so any narrowing you did before has to be done again.