Skip to main content
PMXT normalizes every supported venue to the same three-level shape:
Every response — from the local server, from the hosted Router, or from a hosted venue pass-through — uses the same field names. Write your client once, switch venues with a config change.
PMXT serves reads from a cached Postgres catalog for speed (~10 ms), or passes through live to the venue for freshness. The SDK chooses per-method based on whether the catalog can safely answer; the response envelope is identical either way.

UnifiedMarket

UnifiedOutcome

Identifier semantics are source-aware: Router and hosted catalog rows use stable PMXT UUIDs for marketId and outcomeId. Venue clients and local pass-throughs may use venue-native identifiers. Do not assume every marketId / outcomeId is a UUID or every outcome id is venue-native. See Catalog UUID vs Venue ID when crossing between Router results, hosted trading, and venue-direct clients.

UnifiedEvent

Fields that a specific venue doesn’t expose come back as null. That’s intentional — null always means “venue has no value for this field”, never “PMXT failed to populate it”.

Where the shape is defined

The canonical definition lives in core/src/types.ts in the pmxt repo, and every SDK client (TypeScript and Python) mirrors it. The OpenAPI reference is generated from the same source on every pmxt-core release.