SDK drift: `TradesParams` field names and types differ between TypeScript and Python

[realfishsam]

Drift

The TradesParams type used by fetchTrades has different field names and types in each SDK:

Field purpose	TypeScript	Python
Range start	start?: Date	since?: int (Unix ms)
Range end	end?: Date	until?: int (Unix ms)
Page size	limit?: number	limit?: int
Pagination cursor	(absent)	cursor?: str

start/end vs since/until is a naming inconsistency (not a camelCase↔snake_case normalisation). The cursor field has no counterpart in TypeScript. The Date vs int difference is also a type-level inconsistency beyond language-native numeric mappings.

TypeScript SDK

File: sdks/typescript/pmxt/models.ts lines 568–576

interface TradesParams {
    start?: Date;
    end?: Date;
    limit?: number;
}

Python SDK

File: sdks/python/pmxt/models.py lines 698–704

class TradesParams(TypedDict, total=False):
    since: int    # Unix timestamp ms — field name differs from TS `start`
    until: int    # Unix timestamp ms — field name differs from TS `end`
    limit: int
    cursor: str   # no equivalent in TypeScript

Expected

Both SDKs should use the same field names for the time-range bounds. Either both should use start/end or both should use since/until, and the Python field names should be the snake_case equivalent of the TypeScript names (e.g. if TS uses start/end, Python should also use start/end). The cursor pagination field should either be added to TypeScript or documented as Python-only.

Impact

A caller migrating between SDKs will pass start/end in Python (matching TypeScript) and get no time-range filtering, because the server expects since/until. Conversely, TypeScript callers cannot use cursor-based pagination that Python supports. The type mismatch (Date vs int) also means TypeScript callers must perform a manual conversion that is not required in Python.

---

Found by automated SDK cross-language drift audit