APIs

Event-market data APIs: what builders should normalize first

Event-market APIs are useful only when the response separates public data, derived status, resolution context, and the action an agent should take next.

8 minPublished 2026-05-17 · Updated 2026-05-17

Direct answer

  • Normalize venue id, title, probability, liquidity, spread, expiry, and resolution rules before ranking markets.
  • Keep source status and derived product status separate.
  • Agents need machine-readable caution fields, not only prose summaries.
  • Paid API endpoints should preserve schema versions and not-trade-advice metadata.

Direct answer

An event-market data API should expose normalized market state across venues: venue id, market id, title, probability, liquidity or depth, spread, expiry, source status, derived status, resolution rules, and confidence. Without that model, scanners and agents confuse active markets, expired markets, and officially resolved outcomes.

The API normalization loop

The safest prediction-market workflow separates attention, evidence, source quality, and next action. A probability move can be important, but it is not useful until the market is liquid enough, the rule is clear enough, and the user knows what to verify next.

  • Fetch active markets from each venue.
  • Normalize probability, volume, liquidity/depth, expiry, and status.
  • Classify categories and subcategories with traceable rules.
  • Attach resolution source and rule text.
  • Rank attention queues and expose paid deep-dive endpoints only after the schema is stable.

What to verify before trusting the move

Good research tools keep the boring details visible. Expiry, resolution source, official status, spread, liquidity, and related markets often explain why a headline probability should be treated carefully.

  • Whether the API distinguishes source status from derived status.
  • Whether 99c or 1c prices are marked as pinned rather than settled.
  • Whether schema versions are included in every payload.
  • Whether the response says what the agent should verify next.

How Orrery handles it

Orrery exposes typed x402 endpoints for health, venues, markets, attention queues, market snapshots, why-it-moved explanations, resolution risk, signals, wallets, and watchlist summaries. Each envelope includes schema version, payment status, sources, and not_trade_advice metadata.

Orrery is not a broker and does not provide trade recommendations. It ranks research work, explains market structure, and keeps resolution rules visible so humans and agents can make better verification decisions.

FAQ

What is the first endpoint an agent should call?

An attention queue. It keeps cost and context under control by ranking which markets deserve deeper inspection.

Should an event-market API include resolution rules?

Yes. Market title and price are not enough; the resolution rule often decides whether two contracts are actually comparable.

How should paid API access work for agents?

Use free discovery endpoints, then paid per-call or credit-pack endpoints for deeper data. Orrery supports x402 challenges for paid calls.

Event-market APIs | Orrery