Skip to content

ScaleTrade TCP API - Manager Global Search

MngGlobalSearch

Description: Searches across accounts, orders, groups, and symbols from one manager-facing input. The method is intended for fast navigation in back-office tools and returns typed rows that identify which entity each result belongs to.

Access: Managers only.

Access Scope

The server resolves the manager from the current staff cache. Token payload is used only to resolve the manager id and session type.

Returned rows are limited by the cached manager scope:

  • accounts require access_backoffice, see_accounts, groups, and brand
  • trades require access_backoffice, see_trades, groups, and brand
  • groups require access_backoffice, one of see_accounts, see_trades, or market_watch, plus groups and brand
  • symbols require access_backoffice, market_watch, and visibility through at least one visible group security configuration

Request Parameters

Name Type Required Description
query string Yes Search text. Supports numeric login/order lookup and text search for groups and symbols
limit int No Maximum number of returned rows. Default is 20, maximum is 50

Request Example

{
  "query": "12345",
  "limit": 20
}

Response Parameters

Name Type Description
query string Normalized search query used by the server
count int Number of returned rows
rows array Search result rows

Row Structure

Name Type Description
type string Result type: account, trade, group, or symbol
entity string Entity name: Account, Trade, Group, or Symbol
id string Stable entity identifier as string
label string Human-readable label for UI display
score int Match score. Higher values should be displayed first
data object Type-specific payload

Response Example

{
  "query": "12345",
  "count": 2,
  "rows": [
    {
      "type": "account",
      "entity": "Account",
      "id": "12345",
      "label": "Account 12345 - John Smith",
      "score": 100,
      "data": {
        "login": 12345,
        "group": "real\\standard",
        "name": "John Smith",
        "email": "[email protected]",
        "enable": 1
      }
    },
    {
      "type": "trade",
      "entity": "Trade",
      "id": "12345",
      "label": "Order 12345 EURUSD login 10001",
      "score": 95,
      "data": {
        "order": 12345,
        "login": 10001,
        "symbol": "EURUSD",
        "cmd": 0,
        "state": 0,
        "volume": 100,
        "open_time": 1716200000,
        "close_time": 0
      }
    }
  ]
}

Matching Flow

  1. The server trims query and validates limit.
  2. Numeric queries are checked against account login indexes using an internal candidate pool larger than the response limit, then manager visibility is applied.
  3. Numeric queries are checked against order lookup using an internal candidate pool larger than the response limit, then manager visibility is applied.
  4. Groups are matched by exact, prefix, and contains comparison.
  5. Symbols are matched by exact, prefix, and contains comparison over symbol, description, and source.
  6. Results are scored, sorted by score, and limited to the requested number of rows.

Current Search Behavior

Entity Matching
Account Exact and prefix search by login through account indexes
Trade Exact lookup by order
Group Exact, prefix, contains
Symbol Exact, prefix, contains

Implementation Recommendations

  • Keep search indexes inside the module that owns the data. Account indexes should live in AccountManager, trade indexes in TradeManager, and so on.
  • Keep the primary cache as the source of truth. Secondary indexes should store IDs such as login or order, not full records.
  • Update cache and indexes under the same write lock to avoid seeing a record without its index entry or an index entry without its record.
  • On record mutation, prefer the simple pattern: unindex old record, update cache, index new record.
  • During reads, hold the shared lock only while collecting candidate IDs. Build response rows after the smallest possible candidate set is selected.
  • Avoid full scans over large caches in interactive search paths. For accounts and trades, use exact or prefix indexes first.
  • Do not implement contains search over large account or trade datasets by scanning all records. If contains becomes required, use a dedicated n-gram/trigram index and verify candidates before returning them.
  • Keep limit small and enforced server-side. Global search is a navigation API, not an export API.
  • For order search, exact lookup is recommended until a dedicated order prefix index exists.
  • For group masks, search by group keys first, then expand to logins only when the caller needs account candidates.

UI Recommendations

  • Debounce input before sending requests.
  • Start searching after at least two or three characters unless the query is a full numeric login/order.
  • Display label as the primary text and use type or entity to route the click action.
  • Treat data as type-specific metadata. Do not rely on unrelated fields being present for every row.