Problem.
Clients implementing periodic catchup against OTS (e.g., to recover from missed socket events) have no way to query "what changed since my last sync." They must fetch the full current state every time, which scales linearly with cumulative markers/points/CoTs over the server's lifetime. For long-lived deployments this becomes increasingly expensive.
Proposal.
Add since and before query parameters (ISO-8601 datetimes) to list endpoints, filtering on the most relevant timestamp column for each:
/api/point?since=2026-04-26T10:00:00Z — points with timestamp >= since/api/markers?since=… — markers with start >= since (or production_time)/api/cot?since=… — CoTs with time >= since/api/eud?since=… — EUDs with last_event_time >= since
Why.
Enables incremental sync. A periodic 2-hour re-sync against a year-old server should only fetch ~2 hours of changes, not the entire history. Pairs naturally with existing sort_by / sort_direction and pagination.
Problem.
Clients implementing periodic catchup against OTS (e.g., to recover from missed socket events) have no way to query "what changed since my last sync." They must fetch the full current state every time, which scales linearly with cumulative markers/points/CoTs over the server's lifetime. For long-lived deployments this becomes increasingly expensive.
Proposal.
Add
sinceandbeforequery parameters (ISO-8601 datetimes) to list endpoints, filtering on the most relevant timestamp column for each:/api/point?since=2026-04-26T10:00:00Z— points withtimestamp >= since/api/markers?since=…— markers withstart >= since(orproduction_time)/api/cot?since=…— CoTs withtime >= since/api/eud?since=…— EUDs withlast_event_time >= sinceWhy.
Enables incremental sync. A periodic 2-hour re-sync against a year-old server should only fetch ~2 hours of changes, not the entire history. Pairs naturally with existing
sort_by/sort_directionand pagination.