Recovery
UOF-style stateful recovery — republishes active markets + recent settlements to your AMQP vhost, terminated by snapshot_complete
When to call it
Use this endpoint whenever your AMQP consumer falls behind and you need to resync without polling REST for every match individually. Typical triggers:- AMQP connection dropped and your durable queue’s TTL elapsed.
- Service restart with no persisted last-message timestamp.
- The
<alive>message arrived withsubscribed="0"(producer downtime) — UOF convention is to immediately initiate recovery.
GET /v1/descriptions/producers. Recovery runs per discovered producer; the
catalog’s producer.id matches the product attribute in feed messages, and
its scope can be used as the UOF-compatible recovery path alias.
How it works
You make a single REST call. The server schedules a background replay onto your tenant’s AMQP vhost (the same exchange the live feed uses,ttfeed). For every booked match the replay publishes:
- One
<odds_change>listing the current active B2B market offers with up-to-date odds. - One
<bet_settlement>per match for offers settled betweenafterand now. - One
<bet_cancel>per match for offers voided betweenafterand now. - A terminating
<snapshot_complete request_id="…">so you know the replay is finished.
request_id as
a top-level attribute. Classify replay messages by that positive integer
attribute; the recovery=1 AMQP header remains available but is not required
for correlation. Recovery routing keys use priority lo (vs live hi) and
echo node_id in their final section.
Required scope
- Minimum:
cs2:recovery:initiate
cs2.odds.basic bundle, so existing odds-feed customers don’t need a new key.
Parameters
Full snapshot versus incremental recovery
- Full snapshot: omit
afteror sendafter=0. Ticktock republishes every current active market for booked matches, followed by<snapshot_complete>. It does not query historical settlements/cancels and does not apply the stateful recovery window. - Incremental recovery: send a positive Unix-millisecond
after. Current active markets are republished together with settlement/cancel transitions after that timestamp.
4320 minutes (3 days) and is advertised
by GET /v1/descriptions/producers. It is configurable per deployment, not a
hard-coded global maximum. A positive after older than the configured window
or in the future returns HTTP 422.
Errors
Concurrency
The in-flight lock is keyed on(tenant, node_id). That means:
- Different
node_idvalues from the same tenant can recover at the same time. For example, nodes3001and3002can run independent replays and bind queues to their respective numeric routing-key suffixes. - Same
node_id(including omitting it — empty maps to the implicit slot"global") is serialized. A second request before the first one’s<snapshot_complete>arrives gets HTTP 409. Wait for that envelope, then retry if you still need to.
Example
Client recipe
Detect the loss
<alive subscribed="0"> message. Stop processing live messages until recovery completes — either pause your consumer or buffer the incoming envelopes and apply them after <snapshot_complete>.Initiate the replay
POST /cs2/v1/recovery/initiate_request with after = <unix_ms of last processed message>. The server returns 202 Accepted immediately; the replay is scheduled in the background.Apply recovery envelopes
request_id equals the positive integer you sent. The recovery=1 header and priority lo remain supplementary metadata.Switch back to live
<snapshot_complete request_id="..."/> whose request_id matches the one you sent, your state is in sync. Apply any buffered live messages, then resume normal processing.Routing keys produced
node_id is omitted, the last section is -.
See also
- AMQP messaging feed — the channel your replay arrives on
- UOF REST compatibility — producer discovery and per-producer recovery paths
- Market descriptions — fetch the template + code catalog once at integration time
Authorizations
Tenant API key issued during onboarding
Query Parameters
Unix timestamp in milliseconds for incremental recovery. Settlements / voids strictly after this moment are replayed. Omit or pass 0 for a full active-market snapshot without historical settlement/cancel replay.
x >= 0Client-chosen positive integer echoed verbatim in the root request_id attribute of every recovery XML envelope.
64^[1-9][0-9]*$Optional positive integer client-node identifier. When supplied, it is echoed verbatim in the last section of every recovery AMQP routing key.
64^[1-9][0-9]*$Response
Successful Response
The response is of type Response Initiate Recovery Cs2 V1 Recovery Initiate Request Post · object.