Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
| developers:websocket:orders [2026/03/05 16:43] – [AutoOCO Order] frank | developers:websocket:orders [Unknown date] (current) – external edit (Unknown date) 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | <note warning> | ||
| + | |||
| ===== Order Routing ===== | ===== Order Routing ===== | ||
| Line 85: | Line 87: | ||
| The **OrderPull** message allows pulling multiple orders at once. | The **OrderPull** message allows pulling multiple orders at once. | ||
| </ | </ | ||
| + | |||
| + | ==== Routing Orders on Behalf of Another User ==== | ||
| + | |||
| + | Firms that trade on behalf of their own customers can submit, revise and pull orders for another user without that user being logged in. Set **OnBehalfOfUserName** to the **username** of the user the order belongs to. | ||
| + | |||
| + | The **UserId** field continues to identify the authenticated (routing) user - do not put the customer' | ||
| + | |||
| + | < | ||
| + | **OnBehalfOfUserName** is a username, not a user id. Leave it empty or omit it to trade as the authenticated user - existing applications are unaffected. | ||
| + | </ | ||
| + | |||
| + | Requirements: | ||
| + | |||
| + | * The authenticated (routing) user must have the **OrderRouting** role. This role is not enabled by default - a firm administrator must enable it on that user before any routed order will be accepted. | ||
| + | * The user named in **OnBehalfOfUserName** must belong to the authenticated user's firm or one of its child firms, and must be enabled and not deleted. | ||
| + | * The account must be one the named user is entitled to trade, and it must be subscribed by the authenticated session. | ||
| + | |||
| + | Example **OrderSubmit** on behalf of another user: | ||
| + | |||
| + | < | ||
| + | OrderSubmit { | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | { | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | } | ||
| + | ] | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | The same field is available on **OrderRevise** and **OrderPull**: | ||
| + | |||
| + | < | ||
| + | OrderPull { | ||
| + | | ||
| + | | ||
| + | | ||
| + | | ||
| + | Pulls = [ | ||
| + | { | ||
| + | | ||
| + | } | ||
| + | ] | ||
| + | } | ||
| + | </ | ||
| + | |||
| + | < | ||
| + | Supply **OnBehalfOfUserName** when revising or pulling a routed order as well. If it is omitted, the revision or cancellation is attributed to the authenticated user rather than to the user the order belongs to. | ||
| + | </ | ||
| + | |||
| + | Order validation - roles, entitled exchanges, accounts and permitted order types - is applied using the named user's own settings, not the authenticated user' | ||
| + | |||
| + | Order updates identify both parties, so routed activity remains fully attributable: | ||
| + | |||
| + | * **UserName** - the user the order belongs to. | ||
| + | * **RoutingUserName** - the authenticated user that submitted it. | ||
| + | |||
| + | If the named user cannot be resolved - an unknown username, a user outside the firm hierarchy, a disabled or deleted user, or an authenticated user without the **OrderRouting** role - the order is rejected with: | ||
| + | |||
| + | < | ||
| + | Specified user not found | ||
| + | </ | ||
| + | |||
| + | < | ||
| + | Resolved users are cached, so changes to a routed user's roles, accounts or enabled state may not take effect immediately. | ||
| + | </ | ||
| + | |||
| Line 215: | Line 291: | ||
| | | ||
| | | ||
| - | TrailPrice | + | TrailDistance |
| } | } | ||
| ] | ] | ||