Direct Link: Environments, Hosts, and Tokens
A Direct Link integration talks to four different surfaces, two of them from the end user's browser and two from your backend, and each has its own host and its own credential. This page puts all of that in one place. The step-by-step flow lives in the Direct Linking Integration guide.
Hosts by environment
| Surface | What it's for | Who calls it | Sandbox | Production |
|---|---|---|---|---|
| Participant API | User login, 2FA, session extension, key generation (Steps 1–2) | End user's client | https://sandbox.prophetx.dev | https://www.prophetx.co |
| Geolocation check | POST /ip-geolocation/api/v1/check-ip (Step 5) | Your backend (with the user's real IP) | https://sandbox.prophetx.dev | https://www.prophetx.co |
| Trading API | Key→token exchange, submit_order, get_order, get_balance, cancel_order, fixtures (Steps 2–6) | End user's client (orders) / your backend (fixtures) | https://api.sandbox.prophetx.dev/partner | https://cash.api.prophetx.co/partner |
| WebSocket | Order book + the user's own order updates (Steps 4, 6) | Both | from GET /websocket/connection-config → ws_host | same |
- Keep the
/partnerpath segment on Trading API calls — it isn't optional. - Use
www.prophetx.co, not bareprophetx.co(the bare host returns a 403). - The Trading API is also reachable through
https://www.prophetx.co/partner/...in production; either host works and both carry the same CORS policy. - Pick the WebSocket host up from
connection-configat runtime rather than hardcoding it, and re-fetch it at least every 30 minutes.
Which calls run where
| From the end user's client (browser / app) | From your backend |
|---|---|
auth/login, send-verification-code | Geolocation check-ip (needs the real end-user IP from your inbound connection) |
POST /partner/auth/keys (generate the user's key pair) | Fixture ingest: get_tournaments, get_sport_events, get_multiple_markets, get_price_ladder |
POST /partner/auth/login (exchange key pair for a trading token) | Order book WebSocket under your own account |
submit_order, cancel_order, get_order, get_balance | — |
The user's private orders WebSocket channel | — |
The user's access_key / secret_key and trading access_token must never reach your backend. That's the whole security model of Direct Link — see the security requirement.
CORS
Browser calls to any of these hosts only work if ProphetX has added your web origin(s) to the CORS allowlist. This is per-origin, not open — there's no wildcard, by design. Send your exact origins (scheme + host, e.g. https://app.example.com) to your integration contact before you start client-side testing; until then, calls from the browser will fail with a CORS error even though the same request works from curl or a backend. The allowlist is shared across sandbox and production, so you only need to ask once.
Credentials and lifetimes
There are three distinct credentials in play. Don't mix them up:
| Credential | Issued by | Used for | Lifetime | Renew with |
|---|---|---|---|---|
Participant accessToken | POST /api/v1/auth/login (email/password) | Authorizing POST /partner/auth/keys only | 60 min in production, 15 min in sandbox | Not needed in this flow — it's used once, right after login. Log in again if you ever need it later (e.g. to revoke a key). |
access_key / secret_key | POST /partner/auth/keys | Logging in to the Trading API — nothing else | Until revoked (DELETE /partner/auth/keys/{id}) | n/a — secret_key is only shown at creation |
Trading access_token (+ refresh_token) | POST /partner/auth/login (key pair) | Every Trading API call: Authorization: Bearer <access_token> | 10 minutes | POST /partner/auth/refresh with { "refresh_token": "..." } |
An expired or invalid trading token returns 401. A 404 data_not_found is never an auth problem — see Order lifecycle.
Refresh proactively (e.g. at the 8-minute mark) rather than waiting for a 401 mid-order.
Rate limits
Trading API limits are enforced per user key, per endpoint, in requests per second, and returned as 429 when exceeded. Every linked user has their own budget, so one busy user doesn't throttle another. Self-serve keys start on a conservative tier; if you expect bursts (e.g. many users firing orders at kickoff) talk to your integration contact about tiering before launch. Build against the v4 endpoints (/v4/mm/...) only — pre-v4 legacy endpoints may be rate-limited to zero for newly created keys. Don't poll read endpoints faster than once per second per user — use the WebSocket for anything real-time.
There is no published limit on the participant login endpoints, but call auth/login once per session and keep the token; send-verification-code sends the user a real SMS each time.
Updated 6 days ago