# Users and roles

> Admin and sales roles, module permissions, record visibility, and how API tokens relate to them.

Every API request runs on behalf of a user. This page covers the three layers that determine what that user can see and change.

## Roles {#roles}

| Role | Key | What they can do |
|---|---|---|
| Admin | `admin` | All records, settings, users, apps, the Developers page, license, and invoices. |
| Sales | `sales` | Their own records, plus whatever the visibility rule allows; settings pages are off-limits. |

Only admins can create API keys (**Settings → Developers** (*Ayarlar → Geliştiriciler*)), and a key runs as the admin who created it. If you need an integration that runs with a specific sales rep's permissions, that user must grant access through [OAuth](/rest-api/oauth).

## Module permissions {#modules}

Modules enabled in the license can be further restricted per user (**Settings → Users → user → Modules** (*Ayarlar → Kullanıcılar → kullanıcı → Modüller*)). Endpoints of a module the user doesn't have permission for return `403 module`:

```json
{ "ok": false, "error": "module", "message": "Bu modül lisansınızda / izinlerinizde yok.", "module": "fairs" }
```

Each endpoint's reference page states which module it belongs to. The identity, Today, search, notification, email, and Ask endpoints don't depend on any module.

## Record visibility {#visibility}

**Settings → Security → Record visibility** (*Ayarlar → Güvenlik → Kayıt görünürlüğü*) selects one of two modes:

- **Everyone** (*Herkes*) — sales reps see all companies, but can edit only their own records (or those with no owner).
- **Team** (*Takım*) — sales reps see the companies of users in their own department and companies with no owner; companies in other departments, and records linked to them such as opportunities, tasks, and emails, don't appear in lists.

The API applies this rule exactly: hidden records don't appear in lists, and requesting one by ID returns `403 forbidden` or `404 not_found`. The `scope` parameter on list endpoints (`mine` · `all` · a user ID) doesn't widen visibility; it only filters within what's already visible.

## User lifecycle

- **Invite** — an admin invites the user by email, and the user sets their own password. To provision users automatically from your identity provider, use [SCIM](/rest-api/scim).
- **Deactivate** — a deactivated user can't sign in; their mobile sessions and API keys are revoked immediately, and their OAuth grants become invalid. Their records and history aren't deleted.
- **Seats** — if all seats in the license are taken, you can't create a new user or reactivate a deactivated one.

## Two-factor authentication and IP restrictions

Users with two-factor authentication enabled must send the `otp` field to the [mobile sign-in](/rest-api/auth/login) endpoint. API keys and OAuth tokens don't ask for a second factor — they were already authorized by a signed-in user when they were created.

If an admin has set an IP restriction on a user, requests made with that user's tokens are also accepted only from allowed networks (`403 ip`).