Market data and your brand

You own your product's name, design, navigation and user login. CRISP supplies managed trading and account services behind your backend. Users do not need to leave your product for a CRISP login. Your interface and authentication remain in your application, with trading mediated by CRISP.

To implement the discovery experience, follow Build the Market Discovery like Polymarket does, including SDK helpers for categories, carousels, hot topics and public event feeds.

Market discovery and trading

The current Partner API covers Polymarket market/event reads, outcome books, order requirements, trading status, order placement and cancellation, portfolio, confirmed fills and position redemption. A market being visible does not mean it is currently accepting orders; use trading status and requirements when presenting actions.

Localized display support is available through the localization APIs. Preserve market and outcome identifiers when translating labels. Execution always uses identifiers and current venue rules, not a localized title or cached display price.

Stable fields and venue extensions

Normalized responses provide a typed CRISP display contract. In a normalized market, marketId is the Polymarket condition ID. Outcome token IDs identify individual outcomes and are not interchangeable with that market ID.

Category and end date are not currently part of the normalized market row. Venue payloads expose additional information, but those open extensions are not stable CRISP fields. Isolate their use, handle missing values, and coordinate required additions with CRISP before making them essential to your product.

For an integrated snapshot-to-stream workflow, use Live charts and order books. The SDK handles initial loading, streaming, reconnects and cleanup; your application renders the data.

Charts

The Partner SDK includes getPolymarketPriceHistory() for charts and getPolymarketOrderBook() for order-book snapshots. They call Polymarket's public CLOB endpoints directly from your backend, using the selected outcome token ID. They require no CRISP credentials. See charts and order books.

These are SDK helpers rather than new authenticated CRISP HTTP routes. Upstream availability and rate limits apply; chart data and book snapshots do not authorize trading or replace current order requirements.

Caching and images

Public-data caching can reduce requests and improve browsing. Choose freshness for the use case: a cached discovery page and an order ticket have different needs. Show stale or unavailable data honestly and refresh changing fee rules after configuration updates. Cached books, fee displays and balances are not execution authority; the backend revalidates orders.

Market responses include image URLs that your product can render, subject to your image-host configuration and applicable usage rights. Technical access to an image or venue payload does not establish redistribution or hotlinking rights. Agree caching, image use and attribution terms during onboarding.

Branding and disclosures

The integration does not require a CRISP-hosted end-user interface or impose a technical CRISP badge. Contractual CRISP/venue attribution and required user disclosures must still be agreed. Explain fees, custody and market rules clearly in your own experience; a custom brand does not change how execution or custody works.

Next: plan your integration, or use the market and trading guide.