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

All fields are optional on update. To clear a field that can be empty, pass null
userId is the numeric ID of the user in Exode (the id field in the user/create, user/find or user/list response). If you only store your own identifier, use the external ID extId variant. This method cannot change the password. If there is no user with this userId in the school from the School-Id header, the method returns 401 with cause: "Forbidden" and the message seller not entity owner.
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 the first or last character and cannot be repeated consecutively (automatically converted to lower case). Must be unique within the school. Used for sign-in alongside email and phone.
integer
The user’s Telegram ID. An integer or null. It is not a login: it links the account to Telegram.
string
The user’s external ID from your system. A string of up to 50 characters or null (an empty string resets the value to null). It is not a login: it is used only to link the user to your CRM/LMS and to find the user.
enum
Account status: Active, OnLeave, Banned, Blocked or Terminated.
  • Active: regular access;
  • OnLeave: “on leave”, an informational status that does not block access. It is managed automatically by the absences module; setting it manually is not recommended;
  • Banned: banned. Sign-in is denied and active sessions are terminated. To lift the ban, pass Active: the actual status is recalculated automatically from employments and absences (Terminated / OnLeave / Active), so an employee terminated before the ban does not regain access by mistake;
  • Blocked: blocked. Sign-in is denied, active sessions are terminated and product enrollments are blocked. Returning to Active restores access;
  • Terminated: terminated. Access is closed the same way as for Blocked. It is managed automatically by the employments module (termination of the last active employment); to terminate an employee, use staff/employment/terminate instead of setting the status directly.
The Deleted status is reserved by the system (account deletion) and cannot be passed.
The boolean banned request field has been removed: blocking is managed only via status (Banned / Blocked). The response still includes the banned and active fields, derived from status.
The school owner is protected: another administrator cannot change the owner’s data, and moving the owner to a blocking status (Banned/Blocked/Terminated) is forbidden even for the owner themselves. The method returns the ForbiddenModifySchoolOwner error.
object
Container for related data, the same as in user/create: the staff.employments block (array of 1–10). Corporate schools only; unlike creation, it is optional. Employments are applied idempotently: passing the same active department + position pair again does not create a duplicate.
Via extra in update you can only add employments to an employee. Transfers, position changes and termination are handled by the endpoints in the Staff (HR) section.

Profile parameters

object
Object with the user’s profile data to update.
When updating a user, you can change both the main data and the profile data. If the profile is not specified, it remains unchanged.

Update a user by external ID

Requires authentication and the “School User Management” permission (SchoolManageUsers).
Same as updating by userId, but the user is addressed by the external ID extId within the school. This is convenient for integrations (CRM/1C) that do not store internal Exode IDs. The request body, response, school owner protection and extra support are identical to the regular update.

Parameters

string
required
The user’s external ID within the school. Cannot contain / or whitespace characters; non-ASCII values (Cyrillic, etc.) in the path must be URL-encoded (encodeURIComponent).

Permission requirements

Updating a user requires the “School User Management” permission (SchoolManageUsers).
The service user must be authenticated with a token and have the appropriate access rights to the specified school.
When a blocking status (Banned/Blocked/Terminated) is set, all of the user’s active sessions are terminated automatically. This is done for security reasons.

Updated: 2026-09-25 14:33 UTC