Skip to main content
← Back to the current changelog ← Newer entries: April 27, 2026

​
2026-04-26 — New endpoint: GET /v2/onchain/tags for tag discovery

Lists every tag slug in the polynode taxonomy — currently 5,779 tags. Lightweight by default (just slug strings, 73 KB / 43 ms cold for the full list) or ?details=true for per-tag enrichment (markets, events, first/last seen).
Values returned here are exactly what to pass to ?tag_slug= on the wallet positions and unified positions endpoints. Use it to populate filter dropdowns or autocomplete inputs. The underlying materialized view refreshes hourly so newly-added Polymarket tags appear within an hour.

​
2026-04-26 — Wallet Positions: tag_slugs field + ?tag_slug= filter

Every row of GET /v2/wallets/{address}/positions/onchain now includes a tag_slugs array carrying the Polymarket event-level tags that apply to that market — typical values like nba, basketball, sports, politics, crypto, fed, 2025-predictions, plus event-specific slugs like 2026-fifa-world-cup-winner-595. Order is most-specific to most-general. A new optional ?tag_slug=<slug> query parameter filters the response to only positions whose market carries that tag. Composes with since / until, so you can ask for e.g. “all NBA positions traded in the last 30 days” in one request:
When the filter is supplied, aggregates recompute over the filtered set and the response gains filtered: true plus applied_filters: { since, until, tag_slug } so the behavior is self-documenting. Strictly additive — when no filter param is supplied, the response shape is byte-identical to before. Coverage is effectively universal: tags are populated on every event Polymarket indexes (sampled empirically at 100% in our backfill audit), so any non-test market should return a populated tag_slugs array.

​
2026-04-26 — Unified Trades: additive direction (BUY/SELL) field on /v2/onchain/trades

GET /v2/onchain/trades now also returns direction ("BUY" / "SELL") on every row when filtered by wallet — same semantics as the wallet-trades endpoint, applied to the unified-trades flow. Independent of the existing side field. When no wallet anchor is supplied, direction is omitted (no perspective to derive against). Strictly additive: every other field is byte-identical to prior responses, and queries without wallet are unchanged. Verified live: 1,214 trades cross-checked against Polymarket data-api side — zero drift.

​
2026-04-26 — Wallet Trades: additive direction (BUY/SELL) field

Every row of GET /v2/onchain/wallets/{address}/trades now carries a direction field with values "BUY" or "SELL", derived from whether the queried wallet contributed USDC or outcome tokens on the fill. This is independent of the existing side field, which remains the exchange role ("maker" / "taker") and is unchanged. The two answer different questions:
  • side — did the wallet provide liquidity or take it?
  • direction — did the wallet enter (BUY) or exit (SELL) outcome shares?
All four combinations (maker+BUY, maker+SELL, taker+BUY, taker+SELL) appear in real responses. Strictly additive — every other field is byte-identical to prior responses. The information direction carries was always derivable from maker_asset_id / taker_asset_id (exactly one is "0" on every fill, that’s the buyer). This change just makes the derivation explicit so analytics integrations don’t have to compute it client-side.

​
2026-04-26 — Wallet Positions: per-position timestamps, parent event slug, opt-in window filter

Four new fields on every row of GET /v2/wallets/{address}/positions/onchain (and the unified GET /v2/onchain/positions feed). Two new optional query parameters for server-side window filtering. Every change is strictly additive — calls with no new parameters return responses byte-identical to before. New per-position fields:
  • last_trade_at — unix seconds. Latest fill on this token across V1 + V2 exchanges. The right field for “active in the last 30 / 90 days” leaderboard windows.
  • closed_at — unix seconds. Latest moment the wallet redeemed any outcome of the market for collateral. Distinct from resolved_at — resolved_at is when the market itself resolved on-chain; closed_at is when this specific wallet actually redeemed.
  • resolved_at — unix seconds. Moment the market became redeemable (oracle reported payouts on-chain). Recent markets are fully covered; markets that resolved before polynode began tracking return null.
  • event_slug — the parent event slug, distinct from the per-row slug (which is the per-market slug). For multi-market events (NBA games with several lines, election markets with multiple candidates, FIFA World Cup with one market per team), event_slug is the parent the markets share. For single-market events, event_slug equals slug. Lets you group positions by event without an extra metadata round-trip.
New optional query parameters — opt-in only:
  • ?since=<unix_seconds> — keep positions whose last_trade_at >= since.
  • ?until=<unix_seconds> — keep positions whose last_trade_at <= until.
When either is supplied, all aggregates (count, open_count, closed_count, total_realized_pnl, total_unrealized_pnl, total_pnl, positions_with_pnl) recompute over the filtered set, and the response gains two top-level keys to make the shift self-documenting: filtered: true and applied_filters: { since, until }. These keys are absent from default responses, so existing integrations see zero behavior change.
See the Positions & P&L (Wallet) reference for the full field catalog and filtering rules.

​
2026-04-26 — X Search API beta

New paid endpoints for live X (Twitter) search and account-timeline data. Aimed at teams adding social context next to their prediction-market data — sentiment around a market, replies on a leader’s post, what’s being said about an event.
  • GET /v2/x/search?q=…&max=… — search by query, with full operator support (from:, since:, min_faves:, hashtags, lang:).
  • GET /v2/x/user/{handle}/tweets?max=… — most-recent tweets from any public X account.
Available on starter, growth, and enterprise tiers with monthly quotas of 500 / 1,000 / 5,000. Hard rate cap of 1 request per second per key. Track usage live via X-Quota-Used / X-Quota-Limit response headers. See the X Search API guide for the full schema and examples.