Skip to main content
Configuration metadata for every active prediction-market provider — order types, auth flow, chain, and the token/metadata-key format the frontend needs to look up a market. Call these endpoints when you need to know what a venue supports before you build a request against it. Full parameter reference and a live tester: API Reference.

Base URL

Authentication

None. No auth dependency is attached to this router at all, so no auth headers are checked on any endpoint below, and the router is deliberately excluded from the invite gate that covers the user-facing routers. The curl examples send no credentials.
Gotcha: the active provider set is deployment-specific. Discover it with GET /providers/configs instead of hard-coding the providers shown in the examples on this page.

List provider configurations

Every active provider currently loaded from the provider configuration, cached in-process. The active set is deployment-specific; use this endpoint for discovery instead of hard-coding the examples below. Public endpoint — no auth dependency is attached to this router at all, so no auth headers are checked. Not decorated with a per-route rate limit; only the global default (100/minute) applies.

Request

No parameters.

Response

Gotcha: an empty configs array is a valid response, not an error. It means no providers are currently active.
Gotcha: numeric_id can be null — a provider that is active and fully usable here may still not be registered in the central provider map. Do not key your own storage on it without a null check.

Get a provider configuration

Look up a single provider by id (case-insensitive, trimmed) from the same in-process cache as the list endpoint. Public endpoint — no auth required. Only the global rate limit (100/minute) applies.

Request

Response

Same shape as one entry of configs[] above.
Gotcha: the 404 detail echoes the raw provider_id as sent, not the lowercased/trimmed form used for the lookup. Do not parse it back out as a canonical id.

Providers available to API keys

The subset of active providers whose API-key access is currently enabled. Each active provider id from the config list is checked against its api_access_<provider>_enabled feature flag (5-second cache); a provider with no flag row defaults to enabled. Session and admin callers are unaffected by these flags — this endpoint describes the API-key surface only. Public endpoint — no auth required. Only the global rate limit (100/minute) applies.

Request

No parameters.

Response

providers[] holds provider ids in the same order as the config list, filtered to the enabled ones. An empty array is valid — it means no provider is currently open to API-key traffic.

Provider reference

Snapshot of three commonly configured providers. The live set comes from GET /providers/configs.

Kalshi

Polymarket

Hyperliquid

Configuration fields

What each enum value and flag in the response means. Order types: limit (limit order at a specified price), market (executes immediately), fok (fill-or-kill — complete fill or cancel). Auth flow types: none (no authentication), wallet_signature (sign a message with a wallet), api_key (API-key authentication). Token ID format: opaque (presence-only validation — Kalshi-style tickers) or clob_uint256 (long-decimal uint256 condition tokens — Polymarket, predict.fun, and other CTFExchange forks). Config-driven, so adding a new CLOB venue is a config-row edit, not a code change. Metadata key type: marketId (frontend’s market-metadata cache is keyed by the numeric market id) or conditionId (Polymarket, keyed by on-chain condition id). supports_token_approval: when true, users must approve token spending before placing orders. has_multi_token_markets: when true, the provider’s markets may have more than one tradeable outcome token. supports_walk_the_book: when true, the provider supports market orders that walk through the orderbook.

Integration notes

  • Read the flags above off the response rather than branching on provider id — a new venue arrives as a config row, not a code change.
  • The provider list is cached in-process, so a configuration change can take effect on the next cache load rather than immediately.

Errors

Errors are returned as { "detail": "<message>" }, except 429, which is { "error": "Rate limit exceeded: <limit>" } and carries Retry-After / X-RateLimit-* headers. Unhandled failures are 500 {"detail": "An internal error occurred. Please try again later."}. The Code column holds the exact detail string this router returns, or — where there is none. There is no 401 or 403 on this page: none of these endpoints attach an auth dependency, and the router is deliberately excluded from the invite gate that covers the user-facing routers. POST /providers/configs/reload also lives on this router but is admin-only (forces a cache refresh from the database) and is not part of the public API.