# Get Member Permissions

See exactly what one member can do, permission by permission, and why: from their role, a direct grant, or a company setting. It is the answer MindCloud's own authorization gives.

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

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/permissions' \
  --header 'Authorization: Bearer $MINDCLOUD_API_TOKEN'
```

## Response fields

- `userId` (string): The member's userId.
- `roleId` (string): The role they hold in the company.
- `permissions` (array of objects): Their effective permissions, in key order.
  - `key` (string): The permission key, from List Permissions.
  - `name` (string): The permission's display name.
  - `sources` (array): Where it comes from: role, directGrant (granted to the person outside any role), staff (their MindCloud staff role, which replaces a company role), companySetting (the jobs screen setting), or membership (every member holds it, as analytics:page:view). A permission held two ways names both.