Market lifecycle feed

This channel exists for one job: keeping your own database in sync with DimeTrades’ market catalog in real time, without polling. Every other WebSocket channel (Orderbook & Market Updates) requires you to already know a market’s id before you can hear about it — this one doesn’t. You subscribe once and receive every create and status change, for every market and event, in every category, whether it was triggered by an admin or happened automatically (e.g. a sports market auto-halting on a live odds lock).

The five-minute summary. Connect and emit SUBSCRIBE_LIFECYCLE_EVENTS — no payload, no market id. You’ll receive a LIFECYCLE_EVENT message for every market/event create or status change from that point forward, each carrying a sequenceId. If you ever see a gap in sequenceId (a reconnect, a dropped connection, anything), call GET /api/partner/market-lifecycle-events/replay with the missing ids to recover them — DimeTrades keeps no cursor or delivery record for you; detecting and recovering gaps is entirely your side.

1. Subscribing

socket.emit('SUBSCRIBE_LIFECYCLE_EVENTS', (response) => {
  console.log(response); // { success: true, rooms: ['isv_lifecycle_events'] }
});

No authentication is required to subscribe to this channel today. Unlike SUBSCRIBE_USER_UPDATES, this event is registered with no auth requirement — connecting and subscribing needs no token at all. Treat this as reachable by anyone who can connect to the WebSocket server, not brand-scoped. (The REST replay endpoint in section 3 is different — that one is brand-authenticated.)

No catch-up snapshot is sent on subscribe — unlike the public trades channel, this is live delivery only. If you need history (including everything that happened before you ever connected), use the replay endpoint in section 3. Unsubscribe the same way with UNSUBSCRIBE_LIFECYCLE_EVENTS.

2. The `LIFECYCLE_EVENT` message

{
  "sequenceId": 10452,
  "eventType": "MARKET_STATUS_CHANGED",
  "schemaVersion": 1,
  "data": {
    "marketId": "40996686",
    "eventId": "1557438",
    "fromStatus": "open",
    "toStatus": "halted",
    "reason": null
  },
  "occurredAt": 1753776000000
}

marketId and eventId are always strings, never numbers — even though they look numeric. Parse them as strings; comparing one to a numeric literal will never match.

Field	Meaning
`sequenceId`	Globally ordered, monotonically increasing. This is what you track to detect a gap — never assume you’ve received every id with no holes without checking.
`eventType`	One of `EVENT_CREATED`, `EVENT_STATUS_CHANGED`, `MARKET_CREATED`, `MARKET_STATUS_CHANGED`.
`data`	The full, self-contained payload — everything you need is here, you never need to re-fetch a market/event to interpret this message. A `MARKET_CREATED`/`MARKET_STATUS_CHANGED` payload always includes its `eventId`.
`occurredAt`	Unix ms, when the underlying change actually happened (not when you received it).

Settlement fields

A *_STATUS_CHANGED event whose toStatus is settled additionally carries:

Field	Meaning
`result`	The outcome: `YES`, `NO`, or `VOID` (a refunded market). Present only on settlement — its presence is the signal that this event is final, not just any status change.
`targetSettlementPrice`	The real-world observed value a price-threshold market (crypto, commodity, climate, some economics templates) settled against — e.g. a BTC price or a temperature reading. Present only alongside `result` on a settled price-threshold market.
`targetPrice`	The strike/target value the market was evaluated against, set at creation or reveal — distinct from `targetSettlementPrice`, which is what was actually observed. Same presence rule, and also omitted for a market with no single numeric target (e.g. a “between” bracket).

Neither targetSettlementPrice nor targetPrice is present on a sports or categorical-outcome settlement — those markets have no price concept at all, so only result appears:

{
  "sequenceId": 123790,
  "eventType": "MARKET_STATUS_CHANGED",
  "schemaVersion": 1,
  "data": {
    "marketId": "59300874",
    "eventId": "2044229",
    "ticker": "DTXUSDSEK-5M-26NOV020350-UD",
    "status": "settled",
    "fromStatus": "closed",
    "toStatus": "settled",
    "reason": "Settled NO by the resolution engine (automated)",
    "result": "NO",
    "targetPrice": 9.75464,
    "targetSettlementPrice": 9.74805
  },
  "occurredAt": 1793609419515
}

Ordering: on an active, continuously connected socket, delivery is strictly ordered — an event’s EVENT_CREATED always arrives before any MARKET_CREATED for a market under it. The one case this doesn’t hold across is a reconnect: a live message can arrive before a replay response you requested for an earlier gap finishes — merge by sequenceId, don’t assume socket arrival order is final. Delivery is at-least-once, not exactly-once. Deduplicate by sequenceId before applying an event to your own state.

A new market/event almost always starts at pending, not open — never assume MARKET_CREATED/EVENT_CREATED means tradeable. Creating an event or market through the admin back office always defaults to status: pending with no way to submit it as open directly — confirmed both by reading the creation code and by a live test (a freshly created event + markets all came back pending). Opening it is a separate, later *_STATUS_CHANGED event (fromStatus: pending, toStatus: open) that may arrive seconds, minutes, or much later. Gate any “is this live yet” logic on the market/event’s current status, not on having seen a *_CREATED event for it.

3. Recovering a gap — the replay endpoint

GET /api/partner/market-lifecycle-events/replay?ids=10450,10451,10453
X-API-Key: your_api_key
X-API-Secret: your_api_secret

Same server-to-server auth as every other /api/partner/* route.

{
  "data": {
    "events": [
      { "sequenceId": 10450, "eventType": "MARKET_CREATED", "schemaVersion": 1, "data": { "...": "..." }, "occurredAt": 1753775990000 },
      { "sequenceId": 10451, "eventType": "MARKET_STATUS_CHANGED", "schemaVersion": 1, "data": { "...": "..." }, "occurredAt": 1753775995000 }
    ],
    "requestedIds": [10450, 10451, 10453],
    "missingIds": [10453]
  },
  "errors": []
}

Pass a comma-separated list of the sequenceIds you’re missing — not a range, not a cursor. You are the one who knows which ids you have and haven’t processed; DimeTrades keeps no per-partner delivery record to derive this from.
Up to 500 ids per request. A larger backlog is your own client-side loop — chunk your missing-id list into calls of 500 or fewer.
The response always contains every match for every id you asked for, in one reply — there is no pagination on this endpoint.
missingIds means exactly that — not found. It deliberately does not tell you why: an id that was never assigned to a committed change and an id that’s aged out of retention look identical here. If an id you need is missing and you can’t account for it:

The id might not exist yet

If you’re asking for an id close to or above the highest sequenceId you’ve seen live, it may simply not have happened yet — don’t treat it as permanently lost on the first try. Retry shortly.

The id may have aged out of retention

Replayable history is 7 days by default (admin-configurable, so treat 7 days as the floor to design against, not a guarantee it will never be shorter). A row is only ever deleted once it’s confirmed published to Kafka, so you will never lose an id that hasn’t actually been delivered somewhere yet — but once a row is both published and past the retention window, it’s gone for good. If you were disconnected longer than that, reconcile your state against the existing GET /events / GET /events/details endpoints instead of relying on replay to fill an arbitrarily old gap. Don’t let your own reconciliation loop fall behind by more than a few days without running — a backlog that reaches the retention window becomes a permanent, unrecoverable gap.

4. Putting it together

A minimal, correct client:

Subscribe to SUBSCRIBE_LIFECYCLE_EVENTS.
Track the highest sequenceId you’ve successfully applied.
On every LIFECYCLE_EVENT, if its sequenceId isn’t exactly one more than your last applied id, you have a gap — call the replay endpoint for the missing range, apply what comes back (sorted by sequenceId), then apply the message that revealed the gap.
Deduplicate everything by sequenceId — both across replay and live delivery, and across your own retries.
On reconnect, you don’t get anything different: your local “last applied id” is still the right thing to compare the next live message against, and replay is still how you fill anything in between.

There is no server-side session, cursor, or acknowledgement to manage. All of the above is state you keep yourself.

Getting started

Reference

Events & markets

Webhooks

External Wallet

WebSockets

1. Subscribing

2. The `LIFECYCLE_EVENT` message

Settlement fields

3. Recovering a gap — the replay endpoint

4. Putting it together

​1. Subscribing

​2. The LIFECYCLE_EVENT message

​Settlement fields

​3. Recovering a gap — the replay endpoint

​4. Putting it together

1. Subscribing

2. The `LIFECYCLE_EVENT` message

Settlement fields

3. Recovering a gap — the replay endpoint

4. Putting it together