Activity

Activity is the chronological log of prediction-market trades. Every row is a single fill — one wallet buying or selling one position — already joined to the market, event, category and series it belongs to, so you don’t have to resolve identifiers yourself. The same endpoint also returns a summary view, grouping fills into time buckets when you don’t want the raw log.

Columns

Column	Meaning
`activity`	The type of activity: a buy or a sell.
`timestamp`	When the fill occurred.
`user`	The wallet that traded.
`amount`	Shares bought or sold.
`usdPrice`	Price per share, in USD.
`usdAmount`	USD value of the fill.
`avgBuyingPrice`	The wallet’s average buying price at the time of this fill.
`realizedPnl`	Realized profit and loss, in USD.
`realizedPnlPercentage`	Realized PnL as a percentage of cost basis.
`token`	The position traded.
`market`	The market the fill happened in.
`event`	The parent event of that market.
`tags`	Categories on the event.
`series`	The series the event belongs to.
`txHash`	On-chain transaction hash.
`seqId`	Sequence id, for stable ordering.

The reference columns are what make the log enriched. Each comes back as the resolved entity rather than a bare id, so a row already carries the market’s question, the event’s title and the category labels:

{
  "market": { "id": 1234, "question": "Will X win?", "closed": false },
  "user": { "userId": "0xAb8D...90F1", "displayName": "..." },
  "tags": [
    { "id": 7, "label": "Politics" },
    { "id": 9, "label": "US" }
  ]
}

Resolution is one level deep — see Resolved references.

You still filter on the id fields — marketId, eventId, tagIds, seriesId and positionId — even though rows come back carrying the resolved entity. See Filtering.

Two ways to read it

The log

By default the endpoint returns one row per fill, newest first.

{
  "page": { "limit": 50 },
  "filter": [{ "field": "wallet", "operator": "eq", "value": "0xAb8D...90F1" }]
}

The summary

Pass aggregationWindow to roll fills up into time buckets. Rows are grouped by bucket, activity type, wallet and position — one row per wallet’s buying (or selling) of one position within one window.

{
  "page": { "limit": 50 },
  "aggregationWindow": 4,
  "activityIds": [1],
  "filter": [{ "field": "wallet", "operator": "eq", "value": "0xAb8D...90F1" }]
}

Grains run from hourly to monthly; the API Reference lists the id for each. Omit the field for the raw log.

Measures are aggregated the way each one means something: amount, usdAmount and realizedPnl are summed, while usdPrice and avgBuyingPrice are share-weighted averages — not plain averages, so a large fill counts more than a small one. market, event, tags and series carry through as representative values for the group.

Selecting activity types

activityIds restricts the log to buys or sells. Activity type isn’t part of filter — it’s selected here.

{ "page": { "limit": 50 }, "activityIds": [1] }

All types are returned when omitted. See Filtering for how these fields interact with the rest of the request.

Filtering and search

Filter on wallet, market, event, category, position, timestamp, and the numeric measures — see Filtering for the syntax. searchKey runs a free-text search over markets, combining semantic and keyword relevance, so you can find activity by what a market is about rather than by id.

{
  "page": { "limit": 50 },
  "searchKey": "election",
  "filter": [{ "field": "usdAmount", "operator": "gte", "value": 1000 }],
  "orderBy": [{ "field": "timestamp", "direction": "desc" }]
}

API endpoint

POST /api/v1/activity: chronological log of buys and sells, or a bucketed summary.

Getting Started

Features

Using the API

Activity

Columns

Two ways to read it

The log

The summary

Selecting activity types

Filtering and search

API endpoint

Activity

​Columns

​Two ways to read it

​The log

​The summary

​Selecting activity types

​Filtering and search

​API endpoint

Activity

Columns

Two ways to read it

The log

The summary

Selecting activity types

Filtering and search

API endpoint