Integration with Websockets

Real-time market data — game lines, halves/quarters/innings, and player/team props — is delivered to traders over WebSockets, powered by Talaria, ProphetX's in-house WebSocket platform. This guide covers the full integration: connecting, discovering events, registering subscriptions, and consuming updates.

Talaria is a wire-protocol-compatible in-house replacement for a third-party hosted WebSocket vendor ProphetX previously used — it speaks the identical wire protocol (same event names, same double-JSON-encoded frames, same channel/auth signing scheme) so existing integrations need, at most, a host repoint. That's why the literal event strings below (pusher:connection_established, pusher:subscribe, pusher:signin, pusher_internal:subscription_succeeded, pusher:error, and the "service": "pusher" field) still read that way — that's the wire protocol's own name, not a vendor reference, and it's unchanged on purpose. Nothing else in this guide targets that vendor: connect to, and think of this entirely as, Talaria.

What you need to do

We're splitting market updates that today all flow through a single shared channel into dedicated channels per event (and per prop type). This keeps your feed focused and scales better as market coverage grows.

Migrate from POST /partner/mm/pusher to POST /partner/v4/mm/websocket to get access to the new channel types. The new channels are available in your sandbox environment now — start testing there before the deadlines above.

Before you begin

1. Generate API tokens from the sandbox UI.
2. Exchange your access key and secret key for a session token by calling POST /auth/login.
3. Store the access_token and send it in the Authorization header as Bearer <access_token>.

1. What's changing: the channel model

Today, market_selections updates for every event and every market type flow through one shared channel. Going forward, they're split by event and, for props, by market sub-type:

Both new channel types publish the same pair of binding events: legacy market_selections and CFTC-vocabulary v2.market_selections (strike/price/quantity instead of line/odds/stake) — only the routing changes, not which events are available. Bind v2.market_selections, not the legacy market_selections, to get the CFTC-updated payload shape.

What about the old, third-party-hosted service itself?

Separately from the channel migration above, ProphetX is also retiring the legacy externally-hosted service that Talaria replaces. A few things worth knowing:

• This is already live in sandbox. Sandbox hands back a ws_host today, so if you're connecting there, you're already on Talaria.
• Production is currently running both in parallel (dual-publish), with the legacy service still primary — nothing changes for production connections yet.
• September 16, 2026 is the cutover date. On that date, we stop using the official Pusher-hosted service entirely and move fully onto Talaria. Nothing you need to do differently in your code because of this — everything in this guide (the wire protocol, the event names, the service: "pusher" field) stays the same before and after that cutover, since Talaria will keep speaking this same wire protocol regardless of which service is behind it.

If you're seeing pusher:connection_established after connecting to a ws_host value, that's expected — see the callout above.

2. Connecting

Step 1 — Get your connection config. Don't hardcode these values — fetch them, since they can change:

GET <BASE_URL>/partner/websocket/connection-config
Headers: { "Authorization": "<token>", "Content-Type": "application/json" }

Example response:

{
  "app_id": "<app_id>",
  "key": "<app_key>",
  "cluster": "<cluster>",
  "ws_host": "<talaria_host>",
  "service": "pusher"
}

• cluster is unchanged from before the migration.
• ws_host is the new field: when present, connect to it instead of the default Pusher cluster host. It's live in sandbox now. If it's ever absent from the response, fall back to resolving the Pusher cluster host as before — that's the deliberate rollback path on our end, not a bug on yours.
• There's no ws_port or http_host field — don't build against either.

Step 2 — Connect to Talaria using that config, and capture your socket_id from the pusher:connection_established event:

{
  "event": "pusher:connection_established",
  "data": "{\"socket_id\":\"123.456\"}"
}

Note: data is a JSON string containing JSON — decode it twice to get socket_id.

3. Discover event and market IDs

Before registering, you need the event_id for every event you care about, and — for props — the sub_type for every prop market on that event.

There's currently no endpoint that tells you which sub_types are classified "main" vs. "prop" for a given tournament — that classification is server-side configuration that varies by tournament and can change over time. Subscribing to the event channel always gets you every current main market for that event, regardless of what the underlying list holds at any given time — you don't need to track the main/prop split yourself for that channel.

Ensure you are using the V4 versions of get_markets or get_multiple_markets when searching for sub_type

Fallback reference: sub-types by tournament (point-in-time snapshot)

If you need a starting point before you can call the endpoints above, here's the current breakdown by tournament. This will go stale, and the main/prop split can change — treat it as a reference, not a contract.

4. Register your subscription

POST <BASE_URL>/partner/v4/mm/websocket
Headers: { "Authorization": "<token>", "Content-Type": "application/json", "X-CFTC-Terminology": "true" }

X-CFTC-Terminology: true is what gets you the service=6 channels and the v2.market_selections binding this guide documents (Section 1). Omit it and you're registered on the legacy service=3 path instead, with CFTC-vocabulary events unavailable.

{
  "socket_id": "1234.5678",
  "service": "pusher",
  "subscriptions": [
    { "type": "event",         "ids": ["18756"] },
    { "type": "event_subtype", "ids": ["18756:player_to_record_a_double_double"] }
  ]
}

• event_subtype id format is "{event_id}:{sub_type}".
• The response reflects your complete desired set of subscriptions. Each call's authorized_channel echoes back auth for exactly the channels you listed in that call. This does not by itself tear down channels from an earlier call that you omit this time — see Unsubscribing below for how to actually remove a channel.
• service defaults to "pusher" if omitted — this is the wire protocol's name, not a vendor reference (see the note at the top of this guide), and it stays literally "pusher" under Talaria.

Response

{
  "auth": "<string>",
  "data": {
    "success": true,
    "status": "<string>",
    "updated_at": 1784813285,
    "subscriptions": [
      { "type": "<string>", "ids": ["<string>"] }
    ],
    "authorized_channel": [
      {
        "channel_name": "<string>",
        "auth": "<string>",
        "binding_events": [
          { "name": "<string>", "type": "<string>" }
        ],
        "scope": { "event_id": 0, "sub_type": "<string>" }
      }
    ],
    "channel_count": 0,
    "channel_limit": 0,
    "authenticated": { "auth": "<string>", "user_data": "<string>" }
  }
}

scope appears only on Event channels ({"event_id": ...}) and Sub-markets channels ({"event_id": ..., "sub_type": ...}) — it's not present on the main public channel or your private user channel.

Example response (sanitized)

{
  "auth": "<app_key>:<hmac_signature>",
  "data": {
    "success": true,
    "status": "CONNECTED",
    "updated_at": 1784813285,
    "subscriptions": [
      { "type": "tournament", "ids": ["109"] }
    ],
    "authorized_channel": [
      {
        "channel_name": "private-broadcast-service=6-device_type=5",
        "auth": "<app_key>:<hmac_signature_1>",
        "binding_events": [
          { "name": "tournament_109", "type": "tournament" },
          { "name": "general", "type": "general" }
        ]
      },
      {
        "channel_name": "private-service=6-device_type=5-user=<your_account_id>",
        "auth": "<app_key>:<hmac_signature_2>",
        "binding_events": [
          { "name": "orders", "type": "orders" },
          { "name": "health_check", "type": "private_system_signal" }
        ]
      },
      {
        "channel_name": "private-broadcast-service=6-device_type=5-event=10078829",
        "auth": "<app_key>:<hmac_signature_3>",
        "binding_events": [
          { "name": "market_selections", "type": "market_selections" },
          { "name": "v2.market_selections", "type": "market_selections" }
        ],
        "scope": { "event_id": 10078829 }
      },
      {
        "channel_name": "private-broadcast-service=6-device_type=5-event=10078829-subtype=player_total_hits",
        "auth": "<app_key>:<hmac_signature_4>",
        "binding_events": [
          { "name": "market_selections", "type": "market_selections" },
          { "name": "v2.market_selections", "type": "market_selections" }
        ],
        "scope": { "event_id": 10078829, "sub_type": "player_total_hits" }
      }
    ],
    "channel_count": 4,
    "channel_limit": 400,
    "authenticated": {
      "auth": "<app_key>:<hmac_signature_5>",
      "user_data": "{\"id\":\"<your_account_id>\"}"
    }
  }
}

Field notes:

• subscriptions — echoes back what you registered.
• authorized_channel — one entry per channel you're authorized on. Use channel_name + auth to subscribe. binding_events tells you which event name(s) to bind on that channel — each has a name to bind and a type describing the category of payload (tournament, general, orders, private_system_signal, market_selections). The main public channel and your private user channel each carry two binding events; Event and Sub-markets channels also carry two — market_selections (legacy schema) and v2.market_selections (CFTC schema) — bind v2.market_selections.
• scope — present on Event/Sub-markets channels only. Classify incoming messages by scope, not by channel name.
• channel_count / channel_limit — your current usage and cap. Always read channel_limit from the response — don't hardcode it, as it's configured per deployment environment (sandbox/staging is lower than production) and can change.
• authenticated — auth + user_data needed to complete the sign-in handshake (next section).
• rejected — a partner may see this array if some requested subscriptions couldn't be honored (see Rejection reasons).
• Each channel's auth only works for that channel — reusing one channel's auth to subscribe to a different channel will fail.

5. Unsubscribing

To stop receiving updates on a channel you're currently subscribed to, send the wire-protocol unsubscribe event directly — re-registering with a smaller subscription set does not do this on its own (see the note in Section 4):

{
  "event": "pusher:unsubscribe",
  "data": {
    "channel": "private-broadcast-service=6-device_type=5-event=18756-subtype=first_half_moneyline"
  }
}

• This is fire-and-forget — Talaria stops delivering on that channel immediately, but sends back no confirmation event. Don't wait for one.
• It's scoped to one channel per call — send one pusher:unsubscribe per channel you want to drop.
• Disconnecting the socket unsubscribes you from everything. Reconnecting gets you a fresh socket_id with no channels carried over — you re-register from a clean slate (Section 4).
• There's no per-channel REST endpoint for this. The only REST-level teardown is the legacy DELETE /partner/mm/pusher, which terminates the entire connection, not a single channel — it has no /v4 equivalent and isn't a substitute for pusher:unsubscribe.

6. Connecting end-to-end: the full handshake

1. Get connection config — GET /partner/websocket/connection-config (Section 2)

2. Connect to Talaria and capture socket_id from pusher:connection_established (Section 2)

3. Discover event_id / sub_type via REST (Section 3)

4. Register your subscription — POST /partner/v4/mm/websocket (Section 4)

5. Sign in, using the authenticated block from the register response:

   JSON

   {
     "event": "pusher:signin",
     "data": {
       "auth": "<app_key>:<hmac_signature>",
       "user_data": "{\"user_id\":\"<your_account_id>\"}"
     }
   }

6. Wait for confirmation:

   JSON

   { "event": "pusher:signin_success", "data": {} }

7. Subscribe to each authorized channel, using that channel's own auth + channel_name pair from Section 4:

   JSON

   {
     "event": "pusher:subscribe",
     "data": {
       "auth": "<app_key>:<hmac_signature>",
       "channel": "private-broadcast-service=6-device_type=5-event=18756-subtype=first_half_moneyline"
     }
   }

8. Wait for confirmation, per channel:

   JSON

   { "event": "pusher_internal:subscription_succeeded", "data": "{}", "channel": "<channel-name>" }

9. Bind v2.market_selections and consume (next section).

7. Consuming events

• Bind v2.market_selections on each authorized channel — that's the CFTC-vocabulary event (strike/price/quantity). The legacy market_selections event is also bound on the same channels, carrying the old vocabulary (line/odds/stake); only bind it if you still need that shape. This applies only to the new Event and Sub-markets channels — if you're already consuming the main public channel today, it doesn't change and needs no re-binding.
• Want a public trade tape? That's a separate event — trade_execution (or, on the legacy vocabulary, matched_bet) — and it is not on the Event/Sub-markets channel market_selections lives on. It's bound on the channel from a {"type": "tournament", ...} subscription instead, under the binding name your registration response actually lists (tournament_{id} and/or v2.tournament_{id}) — see WebSocket Events for the exact binding names and payload shape. It's anonymized (price and size, no order ownership). If you need fills on your own resting orders specifically, that's the orders event on your private user channel instead.
• Each channel has its own auth string, returned per-entry in authorized_channel. Subscribe to a channel using that channel's own auth — reusing another channel's auth will fail.
• Payload shape is unchanged from before the channel split.
• Classify incoming messages by scope, not by channel name — this is the single most important behavior change to get right, since Event and Sub-markets channels all publish under the same event name.

8. Sub-type canonicalization

Channel names can't contain - or =, so sub_type values are canonicalized on the way in: lowercased; spaces, /, and - become underscores; anything else is dropped.

Send whatever your market data gave you as-is; use the canonical value echoed back in scope.sub_type as your source of truth for matching.

Current classification rules:

• Halves, quarters, and innings are main markets, not props — e.g. first_half_total, 1st_quarter_spread, 1st_5th_inning_moneyline ride the Event channel.
• sup_moneyline and moneyline_3_way are main markets, despite the naming.
• player_* and team_* are almost always props (the large majority of sub-types), but not exclusively — both_teams_to_score, first_team_to_score, and total_goal_odd_even are props too, without that prefix.
• The main-market list is per-tournament server configuration and can change — don't replicate it client-side. Subscribing to the event channel always gets you all current main markets for that event.

9. Channel capacity planning

• Your channel limit per socket is configured per deployment environment, not per account. The main public channel and your private user channel don't count against it. Read channel_limit from the response every time — don't hardcode it, and don't assume it's the same across environments (sandbox/staging is lower than production).
• The limit counts the cumulative union of channels for a socket — re-registering with different events keeps consuming headroom, it doesn't reset.
• Reconnecting resets it — a new socket_id gives you a clean slate.
• Going over the cap rejects the entire request, with HTTP 400 and reason exceed_subscription_count.
• You get one Sub-markets channel per (event, sub_type) pair. For example, NFL carries 26 prop sub-types — at a 400-channel limit, roughly 15 concurrent NFL events at full prop coverage (~390 channels) would approach the cap. Subscribe selectively rather than to every event's full prop set, and size your usage against the actual channel_limit your account gets back.

10. Rejection reasons

11. Keep-alive & error handling

• ProphetX actively sends a health_check message so you can confirm reachability — this is separate from Talaria's own connection ping.
• Respond to the transport's own ping/pong: protocol v5+ requires responding to every pusher:ping with pusher:pong; later protocol versions can rely on default WebSocket ping handling.
• Transport-level errors arrive as pusher:error.

12. Migration checklist

• Fetch event_id, then sub_type per market (Section 3) — don't hardcode the snapshot tables, and don't assume a static main/prop rule
• Send event / event_subtype entries in subscriptions[], as a complete set on every call (Section 4)
• Classify messages by scope, not channel name or event name (Sections 4 & 7)
• Send X-CFTC-Terminology: true when registering, and bind v2.market_selections on every authorized channel (Sections 4 & 7)
• Handle rejected[] and HTTP 400 exceed_subscription_count (Sections 9 & 10)
• Re-send the complete subscription set on every register call — don't append (Section 4)
• Send pusher:unsubscribe for any channel you no longer want, rather than relying on a smaller re-register alone (Section 5)
• Migrate props before July 29, 2026; migrate main markets before August 12, 2026
• Handle the transport's ping/pong and the ProphetX health_check message separately (Section 11)