Multi-value filters
- Endpoint-specific filters differ by read family. Use the generated API reference for the exact parameter set on each endpoint or tool.
- Multi-value filters such as
traderIds,assetIds,directions, andeventTypescan be passed as comma-separated values in REST.
Historical list reads
Events, messages, and valid closed positions use:startTimeendTimelimitcursor
meta.appliedTimeRange.
Open positions
Open positions are paginated with:limitcursor
startTime or endTime.
Stats reads
Trader and asset stats accept explicitstartTime and endTime filters.
Stats responses echo the applied bounds in filtersApplied.appliedTimeRange.
Cursor rules
- Pagination is forward-only.
meta.nextCursoradvances forward.- Cursors remain usable if matching events disappear between requests.
- Disappeared rows may be absent from later pages.
- Pagination reflects the current eligible set and is not a frozen snapshot.
limitaccepts up to100.
Time rules
- Historical list reads may default to a bounded time window when
startTimeandendTimeare omitted. - Stats reads cover the full accessible history unless explicit bounds are provided.
- If an explicit
startTimefalls outside the accessible range, the server can clamp it forward.
Filtering and suppression
- Some rows may be omitted because they are deleted, tied to ineligible connected entities, or outside the current access policy.
- Suppressed rows are omitted silently rather than returned with placeholder warnings.
- Messages are a feed by default.
traderIds,startTime, andendTimeapply to the message feed itself. - On messages,
assetIds,directions, andeventTypesare compatibility filters that only narrow through linked events. - Eventless messages remain eligible by default, but they are excluded whenever one of those compatibility filters is used.