Execution Feed & Reconciliation

The webhook endpoints are how Novig calls you. The two endpoints on this page are the reverse — you call Novig to observe executions: a live WebSocket tape of every execution platform-wide, and a REST listing of the RFQs you won. Together they let you track fills in real time and reconcile anything you missed.

These endpoints are an observability layer, not part of the trade path. Nothing here affects pricing, selection, or settlement — they exist so you can monitor and reconcile your RFQ activity.

Authentication

Both endpoints use the same OAuth 2.0 Client Credentials token as the rest of the API — see Authentication. Send it as a bearer token:

Authorization: Bearer YOUR_ACCESS_TOKEN

You must be an LP with a registered pricer. The token identifies your LP trader, and that trader must own a live pricer registration (see Registration).

Environment	Base URL
Production	`https://api.novig.us`
QA	`https://api-qa.novig.us`

`GET /rfq/executions` — your executed RFQs

Returns the RFQs you priced and won, most recent first. Use it to reconcile fills and to backfill anything you missed on the live feed.

curl https://api.novig.us/rfq/executions \
  --header "Authorization: Bearer YOUR_ACCESS_TOKEN"

Response

200 OK with a JSON array, ordered by executed_at descending:

[
    {
        "rfq_id": "0193abcd-0000-7000-8000-000000000001",
        "wager": "100.00",
        "price": "0.42",
        "outcome_ids": ["11111111-1111-1111-1111-111111111111", "22222222-2222-2222-2222-222222222222"],
        "executed_at": "2026-06-16T22:13:20Z"
    }
]

Field	Type	Notes
`rfq_id`	UUID string	The executed RFQ.
`wager`	string	Taker stake that filled, in Novig Cash. JSON string to preserve precision.
`price`	string	The price you quoted and won at. JSON string.
`outcome_ids`	array of UUID strings	The parlay legs, ordered. Only the REST listing carries these — the live feed omits them (derive from `rfq_id` there).
`executed_at`	RFC3339 string	Immutable execution time, in UTC. Matches the feed’s value for the same `rfq_id`.

The listing is capped at the 500 most recent executions. Older history is out of scope — pull and persist regularly if you need a longer record. An empty array ([]) simply means you haven’t won any RFQs yet.

`GET /rfq/executions/feed` — live execution tape

A WebSocket broadcast of every successful RFQ execution, platform-wide — not just yours.

wss://api.novig.us/rfq/executions/feed

Open it with the same bearer token in the Authorization header on the upgrade request. The same LP-with-pricer gate applies before the socket upgrades.

The feed is anonymous — it never reveals which LP won. It’s a market-wide print tape, not a per-LP fill stream. To see only your own fills, use GET /rfq/executions.

Message shape

One text frame per execution:

{
    "event": "rfq_executed",
    "data": {
        "offset": 12345,
        "rfq_id": "0193abcd-0000-7000-8000-000000000001",
        "wager": "50",
        "price": "0.5",
        "executed_at": "2026-06-16T22:13:20Z"
    }
}

Field	Type	Notes
`event`	string	The print kind. Currently always `"rfq_executed"`; the envelope is forward-compatible for future kinds, so branch on this value.
`data.offset`	integer	Monotonically increasing sequence number. Use it for gap detection — see below.
`data.rfq_id`	UUID string	The executed RFQ. `outcome_ids` are not on the feed; derive them from `rfq_id` or the REST listing.
`data.wager`	string	Taker stake. JSON string.
`data.price`	string	Execution price. JSON string.
`data.executed_at`	RFC3339 string	Execution time, UTC.

Connection behavior

No replay on connect

You receive only executions that happen after you connect. The feed is live market data, not a replayable log. Connect first, then act — anything that printed before you connected is gone from the socket (use the REST listing to catch up).

Heartbeat every 15s

The server sends a WebSocket Ping every 15 seconds to keep the connection alive through the load balancer’s 30-second idle timeout. Standard WebSocket clients auto-respond with a Pong; you don’t need to send anything.

Detect gaps with offset

offset increases by one per print. If it jumps (e.g. 41 → 44 after a lag or disconnect), you missed prints. Backfill the gap from GET /rfq/executions, then resume consuming the live feed.

Implement reconnection with exponential backoff. On every (re)connect, compare the first offset you see against the last one you processed and backfill via REST if there’s a gap.

How the two fit together

Use case	Endpoint
React to executions in real time	`GET /rfq/executions/feed`
Reconcile / backfill your own fills	`GET /rfq/executions`
Get the parlay legs (`outcome_ids`)	`GET /rfq/executions` (the feed omits them)

The typical pattern: hold the WebSocket open for live prints, and periodically (or after any offset gap) call the REST listing to confirm you’ve recorded every RFQ you won.

Introduction

REST Endpoints

Websocket

GraphQL

RFQs

Execution Feed & Reconciliation

Authentication

`GET /rfq/executions` — your executed RFQs

Response

`GET /rfq/executions/feed` — live execution tape

Message shape

Connection behavior

How the two fit together

​Authentication

​GET /rfq/executions — your executed RFQs

​Response

​GET /rfq/executions/feed — live execution tape

​Message shape

​Connection behavior

​How the two fit together

Authentication

`GET /rfq/executions` — your executed RFQs

Response

`GET /rfq/executions/feed` — live execution tape

Message shape

Connection behavior

How the two fit together