Integration with Websockets

Real-time market data — game lines, halves/quarters/innings, and player/team props — is delivered to Market Maker (MM) partners over WebSockets, powered by Pusher Channels. This guide covers the full integration: connecting, discovering events, registering subscriptions, and consuming updates.

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/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 under the same event name, market_selections — the payload schema itself is unchanged, only the routing changes.

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>",
  "service": "pusher"
}

Step 2 — Connect to Pusher 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 V2 | 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/mm/websocket
Headers: { "Authorization": "<token>", "Content-Type": "application/json" }

{
  "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 subscription set is declarative. Every call states your complete desired set of subscriptions — it replaces, not appends to, your previous call.
• service defaults to "pusher" if omitted.

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=3-device_type=5",
        "auth": "<app_key>:<hmac_signature_1>",
        "binding_events": [
          { "name": "tournament_109", "type": "tournament" },
          { "name": "general", "type": "general" }
        ]
      },
      {
        "channel_name": "private-service=3-device_type=5-user=<your_account_id>",
        "auth": "<app_key>:<hmac_signature_2>",
        "binding_events": [
          { "name": "wagers", "type": "wagers" },
          { "name": "health_check", "type": "private_system_signal" }
        ]
      },
      {
        "channel_name": "private-broadcast-service=3-device_type=5-event=10078829",
        "auth": "<app_key>:<hmac_signature_3>",
        "binding_events": [ { "name": "market_selections", "type": "market_selections" } ],
        "scope": { "event_id": 10078829 }
      },
      {
        "channel_name": "private-broadcast-service=3-device_type=5-event=10078829-subtype=player_total_hits",
        "auth": "<app_key>:<hmac_signature_4>",
        "binding_events": [ { "name": "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, wagers, private_system_signal, market_selections). The main public channel and your private user channel each carry two binding events; Event and Sub-markets channels carry one (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 can vary by account/tier.
• authenticated — auth + user_data needed to complete the Pusher 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. Connecting end-to-end: the full handshake

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

2. Connect to Pusher 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/mm/websocket (Section 4)

5. Sign in to Pusher, 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=3-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 market_selections and consume (next section).

6. Consuming events

• Bind market_selections on each authorized channel. 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.
• 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.

7. 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.

8. Channel capacity planning

• Your channel limit per socket is account-configured. 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 accounts or tiers.
• 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.

9. Rejection reasons

10. Keep-alive & error handling

• ProphetX actively sends a health_check message so you can confirm reachability — this is separate from Pusher's own connection ping.
• Respond to Pusher'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.
• Pusher-level errors arrive as pusher:error.

11. 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 & 6)
• Bind market_selections on every authorized channel (Section 6)
• Handle rejected[] and HTTP 400 exceed_subscription_count (Sections 8 & 9)
• Re-send the complete subscription set on every register call — don't append (Section 4)
• Migrate props before July 29, 2026; migrate main markets before August 12, 2026
• Handle Pusher ping/pong and the ProphetX health_check message separately (Section 10)

Questions about your integration? Reach out to your ProphetX integration contact.