Welcome to the official API documentation prepared for user integration of our Twiser Wokr and Twiser LXP products. This documentation details all the endpoints, parameters, and authorization processes that allow you to establish seamless user management and data exchange (e.g., user creation, update, and access to relevant data) between your external systems and the Twiser platforms. You can quickly access the documentation for the relevant product from the menu on the left. You will find all the necessary information here to complete your integration quickly and securely.
\n","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","toc":[],"owner":"27134951","collectionId":"45cf8441-14c4-48a9-b286-fe332cfdfdf6","publishedId":"2sB2qcD1yv","public":true,"customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"},"publishDate":"2025-07-01T11:10:39.000Z"},"item":[{"name":"Wokr User Integration Document V2.1","item":[{"name":"Login","item":[{"name":"Login","id":"ab3f990d-adea-4b6d-84fa-b8a99fe750c3","protocolProfileBehavior":{"disableBodyPruning":true},"request":{"method":"POST","header":[],"body":{"mode":"raw","raw":"{\n \"Email\": \"{{integrationMail}}\",\n \"Password\": \"{{integrationPassword}}\"\n}","options":{"raw":{"language":"json"}}},"url":"https://{{baseUrl}}/identity/api/auth/login","description":"This endpoint performs an upsert: it creates the user when no match is found, and updates the existing record otherwise.
\nUser matching is resolved in the following order:
\nId — when provided, the user is located directly and all other matching keys are ignored.TenantId + CompanyId + EmailTenantId + CompanyId + EmployeeIdRequired fields. The Required column below applies to create. On update, only the matching keys are required — you may send a single field or the complete payload; both are valid.
Omitted values. As a general rule, fields that are omitted or sent as an empty value are left unchanged. The following fields are exceptions:
\n\n\nUsers who have left the company. A request that does not contain
\nExitDaterestores the user as an active employee: the exit date is cleared and the account is reactivated. When updating a user who has previously been marked as having left, always includeExitDatein the request, or exclude such users from the synchronization altogether. See User Delete for details.
Unrecognized fields in the request body are ignored without error.
\nParentId, ParentEmail, or ParentEmployeeId. To remove a user's manager, send an empty ParentId together with IsGeneralManager set to true; an empty ParentId on its own is ignored.0 = no access, 1 = read-only access, 10 = edit access.This request uses the same endpoint as User Upsert. Sending ExitDate marks the user as having left the company: the account is deactivated, flagged as left, and soft-deleted. The record and its historical data are retained.
User matching follows the same rules as User Upsert — instead of Id, you may also send TenantId + CompanyId together with Email or EmployeeId.
\n\nSubsequent requests. Any later request for this user that does not contain
\nExitDatewill restore the user as an active employee. To keep a user marked as having left, includeExitDatein every subsequent request, or exclude the user from the synchronization.
Reversing this operation. To reinstate a user who has left, send a User Upsert request without ExitDate.
This document outlines the User and Identity Management (Identity Service) API for Twiser products.
\nAll integration APIs operate based on company and tenant contexts. Tenant information and access credentials are provided exclusively by Twiser through a dedicated platform. Without valid company and tenant information, no operations can be performed via the APIs.
\nFor clients using on-premise deployments of Twiser products, some of the configurations and access requirements outlined in this document may differ. This includes, but is not limited to:
\nAPI base URLs
\nSSL certificate management and trust policies
\nInternal firewall and proxy configurations
\nEmail whitelisting domains and SMTP routing
\nIdentity service integration and authentication flows
\nPlease consult your Twiser implementation consultant or system administrator to ensure that the relevant configurations are adapted for your internal environment.
\nBefore initiating data integration with Twiser products, it is recommended to verify the following technical requirements:
\nFirewall configurations
\nEmail whitelisting settings
\nSSL certificate installation
\nAccess to API endpoints
\nTo ensure that system-generated emails are delivered properly, you may need to whitelist the domains of the following email addresses:
\nTwiser products use a socket connection to enable real-time data transfer between the front-end and back-end. In some organizations, this type of connection might be blocked due to network restrictions. To avoid connection issues, make sure the following domains are allowed through your firewall:
\nOur SSL certificates are public and readily accessible. You can export the certificate using the links below. The same certificate is used for both the integration and production environments:
\nIntegration: https://wokr-demo.twiser.com
\nProduction: https://wokr.twiser.com
\nA client must authenticate by calling a login before executing other api calls. Login method requires a ‘email’ and ‘password’ parameters needs to be provided. You may obtain this information from your sales contact.
\nIt is used for creating User for LXP application
\nIt is used to get User list for LXP application
\n","_postman_id":"8a6262b5-6712-4877-9481-5076d0cd1bcf"}],"id":"0a0dbd94-7d0d-4aec-924f-08d4a3ab1eb1","description":"This document outlines the User and Identity Management (Identity Service) API for LXP products.
\nAll integration APIs operate based on company and tenant contexts. Tenant information and access credentials are provided exclusively by Twiser through a dedicated platform. Without valid company and tenant information, no operations can be performed via the APIs.
\nFor clients using on-premise deployments of Twiser products, some of the configurations and access requirements outlined in this document may differ. This includes, but is not limited to:
\nAPI base URLs
\nSSL certificate management and trust policies
\nInternal firewall and proxy configurations
\nEmail whitelisting domains and SMTP routing
\nIdentity service integration and authentication flows
\nPlease consult your Twiser implementation consultant or system administrator to ensure that the relevant configurations are adapted for your internal environment.
\nBefore initiating data integration with Twiser products, it is recommended to verify the following technical requirements:
\nFirewall configurations
\nEmail whitelisting settings
\nSSL certificate installation
\nAccess to API endpoints
\nTo ensure that system-generated emails are delivered properly, you may need to whitelist the domains of the following email addresses:
\nTwiser products use a socket connection to enable real-time data transfer between the front-end and back-end. In some organizations, this type of connection might be blocked due to network restrictions. To avoid connection issues, make sure the following domains are allowed through your firewall:
\nOur SSL certificates are public and readily accessible. You can export the certificate using the links below. The same certificate is used for both the demo and production environments:
\nProduction: https://lxp.twiser.com/
\n