Skip to main content

Request headers

string
required
The service user’s API token in the Bearer YOUR_TOKEN format. The school owner issues the token in the admin panel: Manage → School → For developers → API keys — see the “Authentication” section for details.
integer
required
The numeric ID of the seller — the account the school belongs to. Copy it on the API keys page, in the Integration data → Identifiers card. The token’s permissions are checked against this ID.
integer
required
The numeric ID of the school, found in the same place as Seller-Id. The value must match the seller’s school — otherwise a 400 error with cause: "ForbiddenSchoolMismatch" is returned.
Requires authentication and the “School User Management” permission (SchoolManageUsers).

Request parameters

Sign-in fields (login)

The fields email, phone and domain serve as the login for signing in to the school. To have the sign-in credentials sent automatically, pass at least one of them.
extId and tgId are not logins — you cannot sign in with them. They are used only as identifiers: extId links the user to your CRM/LMS, tgId links the account to Telegram.
The login and password are sent to the user automatically (a few seconds after creation): by SMS if phone is passed and an SMS provider is connected in the school for that phone’s country, otherwise to email; additionally to Telegram if tgId is passed. If no channel is available (for example, only domain is passed, or a phone without a connected SMS provider), get the password from the user’s settings in the account and deliver it yourself.
If you pass the password field, the user gets the specified password instead of a generated one. The sign-in credentials are still sent through the channels above — with your password.
To receive the login and password in Telegram, the user must allow the bot to message them or have an active chat with that bot.
create or upsert? create always creates a new user and returns an error (EmailIsBusy, PhoneIsBusy, ExtIdIsBusy, etc.) if the login or identifier is already taken. If, when syncing from your system, you don’t know whether the user already exists in the school, use user/upsert — it finds the existing user and updates it.
string
The user’s email address. Must be a valid email. An empty string is converted to null.
string
The user’s phone number. Must be in international format (for example, +9876543210). An empty string is converted to null.
string
The user’s domain login. Up to 65 characters: Latin letters, digits, _ and dots — a dot cannot be first/last and dots cannot be consecutive (automatically converted to lower case). Must be unique within the school. Purely numeric values and values like id12345 are reserved by the system and cannot be set manually (DomainIsBusy is returned). If not passed, it is generated automatically in the id12345 format. Useful when logins are generated on your side and the user has no email or phone.

Integration identifiers

string
The user’s external identifier from your system (for example, a GUID from your CRM/1C). A string of up to 50 characters without / or spaces (it is used in the user/ext/{extId}/update path), or null. An empty string is converted to null. Used to link and look up the user (user/find, user/upsert); not used for signing in.
integer
The user’s Telegram ID. An integer or null.

Additional parameters

enum
Account status: Active, OnLeave, Banned, Blocked or Terminated. Defaults to Active.
  • Active — regular access;
  • OnLeave — “absent” (vacation, sick leave, etc.): an informational status that does not block sign-in or access. Managed automatically by the absences module;
  • Banned — banned: sign-in is denied and active sessions are terminated. When the ban is lifted, the effective status is recalculated automatically (based on employments and absences);
  • Blocked — blocked by an administrator: sign-in is denied, active sessions are terminated, and product enrollments are blocked. The user remains visible in reports; switching back to Active restores access;
  • Terminated — dismissed: access is closed the same way as for Blocked. Set automatically on termination of the last active employment; rehiring returns Active.
The Deleted status is reserved by the system (account deletion) and cannot be passed.
The boolean banned field has been removed from the request — blocking is managed only through status (Banned / Blocked). The banned and active fields are still present in the response, derived from status.
string
The user’s password. From 6 to 100 characters. If passed, it is set as the sign-in password instead of a generated one (the credentials are still sent to the user, see above). An empty string is converted to null. Available only on creation (the field is not supported in update and upsert).

Profile parameters

object
An object with the user’s profile data.
When a user is created, a linked profile with the specified data is created automatically. If no profile is passed, an empty profile is created, and the user fills in firstName and lastName on first sign-in.

Additional aggregates (extra)

object
A container for related data applied together with user creation. It currently contains the staff block (employments); other aggregates will be added in the future.
Data not covered by this schema (city, a custom status from your CRM, etc.) is passed via custom fields. Departments, positions and employments are managed after creation in the Staff (HR) section.

Permission requirements

Creating a user requires the “School User Management” permission (SchoolManageUsers).
The service user must be authenticated with a token and have the appropriate access permissions for the specified school.

Updated: 2026-09-25 14:33 UTC