A market-data project does not have to begin with a wallet connection. Start by discovering a small number of public contracts, understanding their identifiers, and recording when you observed them.
Polymarket's international developer overview provides a public-market discovery example using the Gamma API. It also points readers to separate Polymarket US documentation. Keep that product boundary visible in any tool or guide you build for a US audience.
Choose the right documentation
Before using an example, write down which product it targets. The international API overview is not a claim that the same account access, market availability, settlement asset, or order flow applies to Polymarket US.
If your project concerns a US product, follow its own documentation. If you are studying public international market data, label the dataset accordingly rather than implying it describes all markets under the Polymarket name.
Make a read-only discovery request
The developer overview documents a keyset market-discovery endpoint. A small public request can be made without adding wallet or trading code:
curl -G "https://gamma-api.polymarket.com/markets/keyset" \
--data-urlencode "closed=false" \
--data-urlencode "limit=5"
Inspect the actual response before writing a parser. Preserve the market identifiers and the source product, and record an observation timestamp beside the data. Do not assume an identifier from one API surface is interchangeable with an outcome token, event, or display title.
Handle pages and empty results
A first page is a sample, not necessarily the full market universe. If your project needs more, use the endpoint's documented pagination controls. Do not guess a pagination method from another API.
Market discovery and wallet accounting use different API surfaces. After finding the contracts, use the Polymarket Data API v2 wallet guide for public positions, leaderboard reads and cursor handling. For a SQL analysis across many markets, the Dune guide explains table grain, joins and data freshness.
An empty result, a failed HTTP request, and a missing field are different states. Keep them distinct. A data dashboard should not turn a failed refresh into a fresh-looking zero price.
Know what discovery does not establish
A market list does not prove that a trade can execute at a displayed price. It does not establish available size, your account's access, signing credentials, or the final settlement interpretation.
For an observer, a useful next milestone is to link each record to its contract wording and documented price or order-book fields. For an execution system, authentication and order lifecycle handling are separate engineering tasks.
Compare datasets carefully
Kalshi's public-data documentation and Polymarket's developer overview offer different discovery models. Normalize the fields you actually need, but preserve their original identifiers and source observations.
Do not join contracts solely because their titles sound similar. Check outcome definitions, resolution sources, and timing. A cross-venue price gap can reflect different contracts rather than a free return.
Build a transparent first dashboard
Show the dataset's product name, last successful observation, and a stale-data state. Link to the original market and documentation. Make it clear whether a number is a current quote, a previous trade, or an example.
That small, inspectable observer is a better first deliverable than an interface that claims to trade or forecast before those capabilities have been built and tested. Continue with the bot evaluation checklist before adopting community execution code.