Full detail for ONE OR MANY Polymarket prediction markets BY ID — the batch resolver that hands you the OUTCOME ASSET IDS every outcome-level tool needs, plus the oracle, the collateral token, the created/resolved lifecycle with their transaction hashes, the resolution source, the image and the market's written resolution rules. Pass a "|"-separated LIST of ids to resolve a whole batch in ONE call instead of calling once per market, or a group_id to get every market of one event. It also resolves an OUTCOME ASSET ID back to the market that issued it — the way back when an outcome asset id is the only identifier a record left you with. NOT a way to find a market from its wording → run polymarket_find_markets first. NOT current prices or implied probability → use polymarket_market_odds. NOT the fills of a market → use polymarket_market_trades.

Polymarket on Polygon, history from September 2025 onward, down to the second.

FIVE ways in, every one of them optional and every one of them accepting a "|"-separated batch: question_id (the direct lookup — by far the fastest, use it whenever you have it), condition_id, group_id (every market of one event), market_id and outcome_asset_id. question_id / condition_id / group_id are 0x-hex and case-insensitive, so an upper-case or checksummed id works and the "0x" prefix is optional; market_id is the short numeric id; outcome_asset_id is a long DECIMAL number, never hex. Setting more than one key ANDs them — question_id + group_id keeps only those of your ids that belong to that event. Ids that match nothing are simply absent from the result, with no error, so a batch never fails as a whole. Passing NO key returns nothing.

RECOVERING A MARKET FROM AN OUTCOME ASSET ID: many trade records carry an outcome asset id but no market id at all, and this tool is the only way back from one to the other. Pass the ids you are stuck with — batched, not one call each — and read Matched_Outcomes, which names the outcome each of them is.

EXPECT FEWER ROWS THAN IDS, for two ordinary reasons, neither of them an error or a bad id: a sizeable minority of outcome asset ids have no market record at all and return nothing (do not read "no market" as "wrong id"), and two ids belonging to the SAME market — the two sides of a binary market, say — collapse into that market's single row, with both listed in its Matched_Outcomes. The same holds for the other keys: any id that matches nothing is simply absent.

condition_id, group_id, market_id and outcome_asset_id have to be searched for and take a couple of seconds regardless of how many you pass, so batch them rather than calling once per id — and prefer question_id, which answers almost instantly.

Returns one row PER MARKET, newest-created first: Question_Id, Condition_Id, Title, Status, Created_Time / Created_Tx / Created_Onchain, Resolved_Time / Resolved_Tx / Resolved_Outcome (the winning outcome) / Resolved_Outcome_Asset_Id / Resolution_Attempts_Failed, Outcomes (one entry per outcome with its label, asset_id and index), Matched_Outcomes (filled only when you passed outcome_asset_id: the requested outcome(s) this market holds, each with its label and its index, so an asset id maps to a name and a position without a second call), Oracle, Outcome_Token_Contract, Registered_Collateral_Token + Registered_Collateral_Symbol + Registered_Collateral_Decimals (the collateral declared by the market registration), Marketplace, Protocol, Market_Id, Group_Id + Group_Title, Resolution_Source, Image, and Rules — the full written criteria the market resolves on, which is usually the real answer to "how does this market settle?".

Notes: a market counts as resolved only once a resolution transaction has actually SUCCEEDED on-chain: attempts that failed are excluded from Status, Resolved_Time, Resolved_Tx and Resolved_Outcome, so a market whose every attempt failed correctly still reads "open" rather than settled. Resolution_Attempts_Failed reports how many failed attempts that market accumulated — it is 0 for almost every market, and a large number means a settlement that was contested or repeatedly retried before it went through. The registered collateral can differ from the token the market's orders actually settle in (for example USDC in registration versus pUSD in trading), so it is named Registered_Collateral_* here and in polymarket_market_odds, while the traded token is Trade_Collateral_* in polymarket_market_odds and polymarket_top_markets; all USD amounts use the trade record's own decimals. Compare token addresses, not symbols: different contracts can share the symbol USDC. Created_Onchain = 0 means the registration itself is not in the recorded history, so Created_Time is the market's own creation timestamp capped at its first recorded event. A small share of markets carry no outcome asset ids at all — those come back with empty asset_id values and cannot be queried at outcome level. Every row carries that market's full rules text, so a large batch is a large answer — ask only for the markets you need. If you pass more ids than limit, or query an event with more markets than limit, the extra markets are dropped silently (newest kept) — raise limit to match.