# On this page

When you create access keys through the Partner API, two fields control what those keys can do:

- `user_role` controls what your user can do through the **management API** (listing keys, updating org settings).
- `buckets_roles` controls what **S3 operations** the access key can perform on specific buckets.

These two fields are independent. They apply at different times and serve different purposes.

| Field           | Where it applies        | What it controls                                            |
|-----------------|------------------------|------------------------------------------------------------|
| `user_role`     | Partner API calls      | Management scope: list all keys vs own keys, org settings |
| `buckets_roles` | S3 data operations     | What the access key can read, write, or manage per bucket  |

## Two Layers of Access Control

| POST /access-keys           | user_role + buckets_roles      |
|-----------------------------|----------------------------------|
| `user_role`                 | `buckets_roles`                 |
| Management Scope            | S3 Operations (per bucket)      |
| `Admin`                     | All keys, org settings, users    |
| `Member`                    | Own keys only                   |
| Default if omitted: `Member`| ReadOnly Get, list, head        |
|                             | Editor+ put, delete, bucket config|
|                             | Admin All ops, bypasses all checks|

## Organization Role (`user_role`)

The `user_role` field tells Tigris what privileges this user has in your system. You pass it on provisioning, access key, and org management endpoints.

| Value   | What it means                                                               |
|---------|---------------------------------------------------------------------------|
| `Admin` | Full org access. Can manage all access keys, update org settings, and view all resources. |
| `Member`| Standard access. Can only manage their own access keys and resources.     |

The behavioral difference shows up immediately. When you call [List Access Keys](/content/docs/partner-integrations/api/tigris-list-access-keys/index.html) with `user_role: "Admin"`, the response includes **all** access keys in the org. With `user_role: "Member"` (or omitted), you get back **only keys owned by that user**.

This same scoping applies to other management operations. Admin-only operations include:

- **Manage all access keys** — view, rotate, or delete any key in the org, not just the user's own
- **Update org settings** — change org name, quotas, active status
- **Invite and manage users** — send invitations, update roles, remove members

If you omit `user_role`, the user is treated as a `Member`. For most integrations, `Member` is the right default.

## Bucket Roles (`buckets_roles`)

The `buckets_roles` field is an array of `{bucket_name, role}` pairs stored on the access key. Three roles are available: `ReadOnly`, `Editor`, and `Admin`. See the [RBAC permissions table](/content/docs/concepts/authnz/#role-based-access-control-rbac/index.html) for exactly which S3 operations each role permits.

Use "*" as the bucket name to grant access to all buckets in the org. An access key with `{\"bucket_name\": \"*\", \"role\": \"Admin\"}` is treated as a full org admin, bypassing all bucket-level permission checks.

## How the Two Fields Interact

`user_role` and `buckets_roles` apply at different times. Here's how common partner scenarios map to these fields:

| Scenario               | `user_role`   | `buckets_roles`                                               | Result                                                    |
|------------------------|---------------|--------------------------------------------------------------|-----------------------------------------------------------|
| **Developer uploads**   | `Member`      | `[{