User Synchronization
Use user/syncrequest to maintain real-time synchronization of user and account data. This is essential for accurate user and account updates, position and ordertracking, risk management, and auto liquidation/admin alerts.
Signature and Overview
The JSON body for user/syncrequest looks like this:
Parameters
splitResponses(boolean, required) - Mandatory. Should betruefor any B2B vendor.users(number[], optional) - Optional. Do not use if usingshardingExpressionorentityTypes.accounts(number[], optional) - Optional. Do not use if using Socket Sharding.shardingExpression(object, optional) - Controls sharding behavior.divisor(number) - Total number of socket shards desired.remainder(number) - If userId or accountId divided by divisor has a remainder of 1, they will come to the socket with remainder: 1.expressionType(string) - Either"modAccountId"or"modUserId". Determines which entity type’s IDs are used for the modulus operation.
entityTypes(string[], optional) - List of entity types you wish to receive.
Important: You must specify entityTypes now; the default is an empty array! Pass strings such as "user", "account", "fill", "fillPair", "order", etc. These control which updates you receive.
You will receive system events for users based on the expressionType in sharding config, but entityTypes will not filter them out. You’ll still receive signature events even if you aren’t telling entityTypes to watch for them.
Filter by Entity Type
To filter WebSocket updates by entity type, pass an entityTypes string array as described above.
This affects both the initial incoming dataset and the types of updates you receive over the socket’s lifetime.
If omitted, the default is an empty array. This means you will not get updates for most entity types, except some special system events.
Sharding
What is Socket Sharding?
Sharding splits a workload among multiple instances to reduce load on any single actor. For our sockets, this means that if an actor fails, only a subset of users are affected.
Sharding Behavior
- An entity change occurs.
- The server looks at the entity ID and considers the
expressionTypeconfig option passed tosyncRequest. - The entity ID is divided by
divisor—the remainder controls which socket the event is published to. - Create or Update “props” event is fired.
- The vendor socket application processes the event.
- Only the socket with the correct remainder receives the event.
For example, socket A with divisor = 3, remainder = 1 only receives updates when entityId % divisor == 1.
Implementation Example
Set up sharded socket instances by determining the total number of desired shards and configuring that many sockets with corresponding remainders.

