> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novig.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Execution Feed & Reconciliation
> Watch RFQ executions live and reconcile the ones you won
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](/api-reference/authentication). Send it as a bearer token:
```bash theme={null}
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](/api-reference/rfq/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.
```bash theme={null}
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:
```json theme={null}
[
{
"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:
```json theme={null}
{
"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
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).
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.
`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.