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
| 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.
Module permissions
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:
{ "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
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.
- 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 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).