# Get Member Capabilities

See what Cirra lets one member do (web search, files, shell, and each app) and whether their role, their own choices, or the default decided it.

`GET https://connect.mindcloud.co/v2/members/:userId/capabilities`

Permissions: `member:view`.

## Parameters

### Path

- `userId` (string, required): The member's userId, from List Members.

### Headers

- `X-Company-Id` (string): Optional. The id of the organization to act in. Leave it out to act in the API key's own organization. A key can also act in its child organizations, and, with "Use this key across all of your organizations" on, in every organization its creator can open in the app. List them with GET /v2/companies. Every response's X-Company-Id header names the organization it acted in. See [Organizations](https://mindcloud.co/docs/api/rest/introduction/organizations).

## Example request

```bash
curl --request GET \
  --url 'https://connect.mindcloud.co/v2/members/user_2wXk9Lm4Pq7Rz3Ts8Vb1Nc6Hd/capabilities' \
  --header 'Authorization: Bearer $MINDCLOUD_API_TOKEN'
```

## Response fields

- `userId` (string): The member's userId.
- `roleId` (string): The role whose rules apply to them.
- `capabilities` (array of objects): Every key a layer sets for them, in key order. A key not listed follows its fallback (Get Capability Catalog).
  - `key` (string): The capability key, such as files.write or apps.salesforce.contact.update.
  - `value` (string): What Cirra does: allow (asks first unless the thread runs with full access), never_ask (allows without asking), or deny.
    Allowed values:
      - `allow`
      - `never_ask`
      - `deny`
  - `layer` (string): Which layer decided it: default, role, or user (the person's own rules).
    Allowed values:
      - `default`
      - `role`
      - `user`