partners.centaur.io has been retired
The old hostname has been removed from hosting and DNS. It no longer serves requests or redirects. This replaces the 308/410 behavior announced on 30 September.Use https://api.centaur.io/v1 or /v2 for REST, https://mcp.centaur.io/mcp for MCP, and https://docs.centaur.io for documentation. Update REST base URLs and reconnect MCP clients using the migration guide.
Source text format and widget asset validation
source.text is the source message as stored. Telegram text is a subset of Telegram HTML (for example strong, em, a, code, pre and blockquote) with escaped entities. X text is plain text with &, < and > escaped.
- Sanitize it with an allowlist, or strip the tags and decode the entities, before display. Never insert it as raw HTML.
source.text itself is unchanged: REST, MCP, x402, widget and webhook payloads return it byte-identical to the stored content.
- Hosted widget endpoints
GET /v2/widgets/{widgetId}/feed and GET /v2/widgets/{widgetId}/positioning now return 422 INVALID_OPTIONS for asset IDs that do not exist or have no active market. Previously the feed returned no items and positioning returned snapshot: null.
partners.centaur.io retires on 29 October 2026
- The new hosts went live on 29 September 2026:
https://api.centaur.io/v1 and /v2 for REST, https://mcp.centaur.io/mcp for MCP, https://docs.centaur.io for the docs. https://partners.centaur.io/docs already redirects here.
- Until 29 October 2026,
partners.centaur.io keeps serving REST and MCP unchanged, and api.centaur.io accepts the old /api/v1 and /api/v2 paths as aliases.
- The original plan was to return
308 redirects for REST and 410 for MCP after 29 October. That plan was superseded by hostname removal on 29 October 2026; see the update above.
- See Migrating from partners.centaur.io for the URL table and the steps per surface.
New API and MCP hosts
- REST moves to
https://api.centaur.io/v1 and https://api.centaur.io/v2, and MCP moves to https://mcp.centaur.io/mcp. Endpoints, responses and REST API keys are unchanged. MCP clients reconnect to the new URL and may need to sign in again.
- The OpenAPI documents list the versioned base URL as their server, so operation paths no longer carry the version prefix.
partners.centaur.io keeps serving for one month after launch. See Migrating from partners.centaur.io.
- Every list and stats response (REST and the matching MCP tool results) now includes
meta.serverTime: the server’s UTC time when the response was produced, as an ISO-8601 string. Existing response fields are unchanged.
- Use
meta.serverTime from your most recent response as the anchor when resolving relative-time phrases such as “today”, “this week”, or “last 7 days” into explicit startTime and endTime values. When the server applies a default history window, appliedTimeRange.endTime is taken from the same request clock and matches serverTime to within a few milliseconds.
- The
filter-guide MCP resource no longer embeds a timestamp of its own. Hosts commonly cache resource reads for a whole session, so the guide now directs callers to meta.serverTime first and to their own clock only before the first tool result.
Ranking window defaults, validation, and coverage
- Trader rankings now default an omitted sample to UTC year-to-date and an omitted performance evaluation window to
30D. Explicit values remain unchanged.
- Structurally invalid REST sample and evaluation combinations return
422 with requested and resolved values plus valid retry alternatives. MCP returns a tool error with the same structured details. Neither interface substitutes or retries automatically.
- Performance ranking and trader stats responses now expose sampled and scored position counts plus their coverage ratio. Partial coverage remains valid when the normal minimum scored-position requirement is met.
- Trader stats rows (
GET /api/v1/traders/stats and the list_trader_stats MCP tool) now include tags: editorial trader tags as { category, name } pairs, lowercase, e.g. { "category": "thematic", "name": "ai capex buildout" }.
- The first shipped category is
thematic: which macro themes a trader’s book expresses (AI capex buildout, power and energy, critical metals and minerals, robotics, macro rotations, crypto). Categories are an open set and may grow without a version bump.
tags is always present and empty for untagged traders. Tag visibility follows the same trader visibility rules as the rest of the stats row.
Partner Feed
- Added
GET /api/v1/feed and the list_feed MCP tool: presentation-ready source-message groups that embed the source preview, source identity, trader, and asset display fields needed for direct rendering, ordered by source-message post time.
- Server-side curation removes fabricated events with no message evidence: assumed and GC-generated closes, instant opens fabricated at a position’s close, and assumed opens siblinged with another event for the same message and asset. Lone inferred opens remain visible with
assumed: true, and retrospective events remain flagged with retrospective: true.
limit counts source-message groups (default 20, maximum 100). traderIds and assetIds filters plus startTime/endTime bounds select groups by source-message post time.
cursor scrolls back through older groups. since is an ingestion-watermark change feed with whole-group upsert semantics: merge returned groups by id and replace each prior payload. The two parameters are mutually exclusive; persist the newest non-null nextCursor after every successful poll, including empty polls.
- The feed uses the new
feed.read scope on REST API keys and MCP OAuth connections. MCP connections authorized before the scope existed need one disconnect and reconnect to pick it up; API keys are unaffected.
- Added the Partner Feed guide and updated query-semantics, data-reads, and MCP docs for the new read family.
Trader rankings and activity summaries
- Added
GET /api/v1/traders/rankings and the rank_traders MCP tool: server-side trader ranking by event_count (default), position_count, win_rate, avg_return, median_return, or sharpe_ratio over an explicit UTC time window, without supplying trader IDs.
- Performance-metric rankings evaluate the
timeBasedPerformanceWindow (default 7D) and require minPositions evaluated positions (default 3); rows expose the evaluated sample size. Windows whose startTime is more recent than the evaluation window are rejected with a corrective 422 instead of returning a silent empty ranking.
- Added
GET /api/v1/activity-summaries and the summarize_message_activity MCP tool: deterministic message and event counts grouped by trader or overall, bucketed by hour, day, or week. Activity summaries are count evidence, not generated narrative summaries.
- Both reads use the
stats.read scope, default to the last 7 days, and return small bounded results (default limit 10, maximum 50) with no pagination. Activity summary requests above 168 buckets per group are rejected with 422.
- Updated MCP capabilities and filter-guide resources so ranking, count, and trend prompts route to the aggregate tools instead of paging
list_events/list_messages.
Trader discovery trade counts
- Trader discovery rows now include
tradeCount, the eligible visible position count for the discovery result.
GET /api/v1/traders and list_traders now accept minTrades, defaulting to 3; pass minTrades=0 for the full visible trader directory.
- Trader discovery now accepts
startTime and endTime to scope tradeCount and minTrades by position open time.
- Updated REST, MCP, and platform docs to identify trader discovery as the supported source for discovery-level activity counts.
Source-aware payloads
- Message rows now expose source metadata under
source.identity and message display data under source.preview.
- The old flat message
url, text, attachments, and originalCreatedAt fields were replaced by the nested source payload.
source.platform can be TELEGRAM or X, enabling platform-specific links, labels, avatars, and audience counts.
GET /api/v1/messages, list_messages, and delegated chat assistant message reads now accept sourcePlatforms for Telegram-only or X-only message feeds.
- Trader discovery and trader stats rows now include one
source identity, and their reads accept sourcePlatforms.
Opaque Source Message IDs and X-backed message reads
- Source Message IDs are now opaque identifiers returned by source-message views, not Telegram channel/message tuples.
GET /api/v1/messages, list_messages, and event messageId hydration use those opaque IDs through ids.
- Source-message URLs may point to Telegram or X depending on the source platform.
Product and contract documentation refresh
- Replaced the old Arena product page with current product-surface docs for Trader Discovery, Asset Discovery, Feed, Following, profiles, Assistant, and source transparency.
- Added API-key, Connected Apps, and contract-limit guides for REST, MCP, and agent clients.
- Clarified messages vs events vs positions, positioning vs performance, event classification flags, and time-based performance windows.
- Updated REST docs to list generated channel and aggregate summary endpoints as first-class read families.
Event and message contract compaction
- Event rows now return flat
type, positionId, and messageId fields instead of eventType, nested position, or nested source.
- Event reads now filter event kinds with
types.
- Message reads now hydrate Source Message IDs with
ids and no longer expose traderId or event-derived filters.
Generated narrative summary guidance
- Clarified MCP and docs language for channel and aggregate summaries as generated narrative summaries.
- Added guidance that generated narrative summaries are useful for market narratives but are not evidence for exact trade counts, public activity rankings, or current open-position skew.
- Clarified that current positioning claims should use open-position reads.
Position History Reads
- Replaced
GET /api/v1/positions/closed/valid and list_valid_closed_positions with GET /api/v1/positions and list_positions.
- Position history reads return open and closed positions by open time with
1D, 7D, and 30D time-based performance.
- Open-position reads continue to expose current marks and live mark-to-market returns.
Centaur API naming
- Updated user-facing copy to use “Centaur API” and “Centaur MCP”.
- Updated examples to use a generic
<api-key> placeholder.
Trader-attributed channel summaries
- Added top-level
traderId to GET /api/v1/channel-summaries and list_channel_summaries results so clients can connect summaries from the same trader over time.
- Channel summaries still do not accept trader or Telegram channel filters, and they do not return trader metadata, channel identity, or raw source material.
- Generated aggregate summaries remain source-anonymous and unchanged.
Summary access
- Removed the separate Summary Entitlement row-returning gate from generated channel and aggregate summaries.
- Summary reads still require
summaries.read authorization through REST API-key permissions or MCP OAuth scopes.
- New default Centaur API keys include
summaries.read.
Generated aggregate narrative summaries
- Added
GET /api/v1/aggregate-summaries and list_aggregate_summaries for cross-source generated aggregate narrative summaries.
- Aggregate summaries use
summaries.read, support Source Window-style overlap filtering, and default to safe summaries.
- Public responses expose source coverage counts but not trader or channel identities.
MCP OAuth eligibility
- Changed MCP OAuth eligibility from existing active API-key ownership to an active Centaur account with a verified email.
- REST remains API-key based, and generated summaries require normal
summaries.read authorization.
- Runtime reads now reject API-key and OAuth owners whose Core account later becomes blocked or unverified.
Source Window overlap filtering
- Changed
GET /api/v1/channel-summaries and list_channel_summaries so startTime and endTime select summaries whose Source Windows overlap the requested interval.
- A Source Window now matches when
windowEnd is after startTime and windowStart is before endTime.
- This fixes daily summary reads so UTC day bounds return summaries covering that day instead of summaries selected only by their window end timestamp.
Documentation and client guidance
- Updated the OpenAPI descriptions, REST docs, MCP filter guide, and public skill guidance to describe Source Window overlap semantics.
Messages now default to feed semantics
- Changed
GET /api/v1/messages and list_messages to return eligible messages even when they have no linked extracted events.
- Kept
assetIds, directions, and eventTypes as filters that narrow messages through linked events when supplied.
- Superseded on 2026-06-13: message reads now support Source Message ID hydration with
ids plus time bounds, limit, and cursor; trader, asset, direction, and event-type filters are no longer part of the public message contract.
Documentation and MCP guidance
- Clarified the new message-feed behavior in the public docs, generated API reference, and MCP filter guidance resource.
- Kept the response shape and pagination contract unchanged.
Broader read surface
- Expanded the documented and generated REST surface beyond events to cover messages, positions, and stats under
/api/v1.
- Expanded the documented MCP surface to cover the same read-only trading data families across events, messages, generated summaries, positions, discovery, and stats.
Query and pagination updates
- Removed
allTime from the public date-range contract. Time-bounded reads now use startTime and endTime.
- Standardized list-style reads on forward-only cursor pagination and documented the applied time bounds echoed back in relevant responses.
Access and authentication behavior
- Clarified that returned data can reflect current access and eligibility rules, so visible rows and available history can vary by caller context.
- Hardened event pagination so paging remains stable even as the currently visible result set changes.
Documentation and client guidance
- Reframed the docs around a broader read-only trading data surface instead of an events-only product view.
- Added a data-reads guide, aligned public skill guidance, and refreshed client setup docs to match the expanded REST and MCP surface.
Task-first onboarding
- Reworked the homepage around access, path selection, and quickstarts for both REST and MCP.
- Added concrete MCP setup guides for Claude Code, Cursor, and Codex.
API reference improvements
- Strengthened the generated OpenAPI-backed reference with richer examples and schema descriptions.
- Kept Swagger available as a secondary technical artifact rather than the primary docs surface.
- Reworked the MCP/API docs around task guides, generated API reference, and changelog pages.
- Moved public skills into a more clearly supplemental role within the docs.
Last modified on October 29, 2026