GET /v2/feed returns a partner-native feed grouped by source message, designed for direct rendering. Its curation rules match the Centaur app feed’s, but the feed is its own documented contract: behavior changes ship as documented API updates, not as side effects of app changes.
Feed groups must pass both the trader’s signal and message visibility gates. The feed only shows activity whose source message the caller is entitled to read, so /events can intentionally return events for a trader that never appears in /feed.
Short-duration positions and their events are excluded before feed pagination. Mixed groups retain their original source text and eligible events. Empty groups are omitted. A fresh list reconciles removals; since returns upserts and does not report deleted groups.
Freshness
The default unfiltered first page can reuse results computed within the last 10 minutes. After 60 seconds, a request triggers a refresh while receiving the existing page. A cache miss or an older page waits for a fresh read.meta.dataComputedAt reports when the data read began. meta.serverTime reports when the response was produced. meta.appliedTimeRange describes the returned data’s query window, including on cached responses. Messages outside the rolling history window are never served from the cache.
Filtered requests, explicit time bounds, non-default page sizes, later pages, and since polling use live reads. REST and MCP use the same freshness policy.
Supported parameters
traderIdsassetIdsstartTimeendTimelimitcursorsince
limit counts source-message groups, defaults to 20, and accepts up to 100. The feed contains only source messages posted during the rolling seven days before the request. startTime and endTime can narrow that window, and an earlier startTime is clamped to its lower edge. A range that ends before the window starts therefore returns an empty page rather than an error. The applied bounds are returned in data.meta.appliedTimeRange.
cursor and since are mutually exclusive. The tokens are opaque and signed, so store and return them unchanged.
Initial read and scroll-back pagination
writtenAt descending with Source Message ID as the tiebreak. Events inside a group are ordered by timeOfEvent descending with event ID as the tiebreak.
When meta.hasMore is true, pass meta.nextCursor as cursor to fetch the next older page:
since; the feed does not scroll beyond the rolling seven-day window.
Polling with since
since is an ingestion-watermark change feed. It is based on newly visible event-log rows, not message post time, so a retrospective event can make a source-message group within the rolling seven-day window reappear.
Pass the latest meta.nextCursor as since:
id as the key.
If a change response has hasMore: true, continue passing its nextCursor as since until hasMore becomes false. Every successful since poll returns an updated non-null nextCursor, including polls with no groups, so store the newest token for the next poll.
Event IDs can be allocated before concurrent transactions commit. Keep the token from before the latest successful poll for one additional cycle and replay it once as a small overlap, merging results by group id and replacing each complete group payload while continuing forward with the newest token. This lets a late commit appear without moving the primary polling cursor backward.
Server-side curation
The partner feed removes fabricated events that have no message evidence or duplicate the message’s real event:- assumed and GC-generated closes
- instant opens fabricated at a position’s close
- assumed opens with another event for the same message and asset
assumed: true, as do assumed increases and decreases. Retrospective events remain visible with retrospective: true.
Centaur may exclude specific sources from the feed for editorial or quality reasons. Those exclusions apply only to this curated feed; raw reads such as events, traders, positions, and messages are unaffected.
Response boundaries
Each group embeds its source preview, source identity, trader display summary, and asset display summary, so clients do not need extra hydration calls to render it. Feed events do not include close timestamps, close prices, realized returns, ROI, time-based performance, inferred display objects, or anautoGenerated flag. Use position and stats reads when you need supported performance data.