How to export your Polymarket trade history for your records

The short way

Find the address that holds your positions, then page the activity feed for it from the very beginning, with every activity type, until the cursor runs out. Everything else on this page is a way of doing that without writing the loop, or a reason the obvious version comes back short.

Polymarket's Data API is keyless and free, and its GET /v2/activity route is the account's timeline rather than its trades: the OpenAPI description calls it an activity feed of "trades, splits, merges, redeems, …", ordered by block timestamp, up to 1,000 rows a page, paged by an opaque cursor until next_cursor comes back null. The two parameters that make it complete are the ones a first draft leaves out.

# Full history: start=1 (omitting start floors the window to three years back).
# Deposits and withdrawals are excluded unless you say otherwise.
curl "https://data-api.polymarket.com/v2/activity?user=YOUR_WALLET_ADDRESS&start=1&limit=1000&sort_direction=ASC&exclude_deposits_withdrawals=false"
# Then repeat with &cursor=NEXT_CURSOR_FROM_THE_RESPONSE, keeping sort_direction, until next_cursor is null.

Each row carries type, timestamp, condition_id, token_id, outcome, side, size in shares, usdc_size in collateral, price and transaction_hash, which is the part an accountant or an auditor actually wants: every line can be found again on Polygon by anyone. Save the raw JSON as well as whatever spreadsheet you flatten it into, because the flattening is where decisions get made.

What the options are

polymarket-client, Polymarket's own Python SDK, wraps the same feed. Its list_activity method pages for you, takes an activity_types filter, and accepts full_history=True so that the default window does not quietly drop the start of an old account. Data API v2 support arrived in version 0.10.0 on 10 September 2026, and the library is on a 0.x line whose minor releases break things, so pin the version you exported with.

PolyTaxes is the version for someone who wants the rows already matched. It takes a public address, a profile URL or a username — no key, no signature — and reads the chain itself, decoding order-book buys and sells, splits, merges, redemptions, neg-risk conversions, token transfers, deposits, withdrawals and maker rebates, then matches lots first in, first out. The output is a Form 8949 CSV, a Schedule D summary, a transaction list and a TurboTax upload file. The preview is free and shows the totals; the files are 29 US dollars per tax year, and the vendor's own pages state that price three different ways, so confirm before paying for more than one wallet. Wash-sale flagging is on by default, which is a treatment choice, not a reading of the record.

PredictFolio is free and lighter. Its beta yearly transaction report covers each verified wallet, with realised profit and loss and fees, as a PDF or a CSV. It does not say which cost-basis method it uses or which country's rules it follows, so it is a ledger to hand on rather than a form. Its importer will take another venue's export, Kalshi's included, so a two-venue year can sit in one place.

The Polymarket US API is a different system under the same brand, and nothing above reaches it. Polymarket US is a regulated exchange run by QCX LLC, settling in dollars in an account rather than on a chain, so there is no address to paste. Your history comes from GET /v1/portfolio/activities on the signed trading host, filtered by type — trades, position resolutions, deposits, withdrawals, referral bonuses, transfers, taker-fee rebates and liquidity program payments — and paged by cursor. Each trade row carries its price, a decimal quantity, a cost basis, realised profit and loss, and whether you were the taker. The exchange's institutional reporting track adds CSV downloads and two streaming ledger exports, position and cash, that start on 1 May 2026 and cannot reach before it.

Where this breaks

The default window is three years, not forever. On /v2/activity and /v2/trades, an omitted or zero start floors to three years back; the description says to pass start=1 for full history. An account from the 2022 or 2023 cycle exported with the default looks complete and is not. The SDK's full_history=True exists for the same reason.

A trade list is not the record. /v2/trades is the obvious endpoint and the wrong one for this job. It serves fills only — and by default each fill once, on its taker side, above a minimum size of 0.01 — so a maker's resting orders, splits, merges, redemptions, rewards and rebates are all missing. Splitting collateral into a YES and NO pair, merging a pair back, redeeming after resolution and converting in a multi-outcome market each move value with no trade attached, and a position closed by redemption has no sell at all. That is why the activity feed, not the trade feed, is the export.

Some rows are opt-in even on the activity feed. Deposits and withdrawals are excluded unless exclude_deposits_withdrawals=false is passed — the wallet-activity page notes they stay excluded "even when type requests them". Tips, user-to-user collateral transfers that are not trades, are never in the default set and appear only when TIP is named in type.

A partly filled order is several rows with nothing joining them. The activity row has no order identifier: an order that filled against three counterparties in three transactions is three rows, each with its own hash, size and price. Summing them is your step, and so is deciding whether they are one lot or three. On Polymarket US the documentation draws the line explicitly — an execution is a state change on one order, a trade is a matched event between two, and a trade moves through states before it is final — so filter on state before you sum.

There is no fee column on the row. The v2 activity schema carries price, size and usdc_size and no fee field; Polymarket's position objects carry entry fees separately and already exclude them from entry cost. Whatever reconciles your cash has to bring fees and rebates in from those other rows rather than out of the trade line.

"USDC" in a field name is not USD, and is no longer even USDC. Trading collateral on Polymarket is now pUSD, an ERC-20 on Polygon backed by USDC and wrapped from USDC.e, while the API's fields are still named usdc_size and entry_cost_usdc. None of it is a dollar amount in a bank. A record that needs a fiat value per row needs a dated conversion the export does not provide, and some practitioners treat the stablecoin leg as its own layer — which is exactly the question PolyTaxes' pages leave unanswered. Polymarket US rows are in dollars and have no such leg.

The wrong address returns an empty, valid history. Polymarket trades from a smart wallet, not the key that signs: a Deposit Wallet for accounts created from 4 May 2026, a Proxy wallet for older email and Google logins, a Safe for older browser-wallet logins. The address the API keys rows on is proxy_wallet. Paste the signer and the feed answers with nothing, which reads like a quiet year. Several addresses are several exports, and the totals do not deduplicate themselves.

Two Polymarkets, two records, never one. A US resident on Polymarket US and anyone who also traded the international venue holds two histories in two units under two operators, and no tool on this page reads both. PolyTaxes says plainly that off-chain US activity cannot be inferred from a wallet. Keep them as separate record sets.

If you outgrow this

If the export becomes a recurring job rather than a once-a-year one, pull it monthly and keep the raw pages: a retrieval floor like Polymarket US's 1 May 2026 is not something you can wait out, and the Data API's own v1 routes retire on 24 October 2026, so a script written against them stops then. If you want the same events without trusting anyone's API at all, the transaction hashes are the bridge to the chain itself — what wallet tracking shows covers what that record can and cannot tell you. And for which venue sends paperwork, and whether it is a form or a statement, read who sends you a tax form before January rather than in it.