> ## Documentation Index
> Fetch the complete documentation index at: https://docs.polaris.supply/llms.txt
> Use this file to discover all available pages before exploring further.

# Intents and RFQs

> Query canonical RFQ, quote, and executable-intent observations across supported venues.

Use the intent method to read RFQs, solver or venue quotes, executable orders,
and settlement updates through one canonical `IntentEvent` shape. Pass
`market="intents"` and use the [Catalog](/reference/catalog) to confirm the
source IDs and historical range currently available to you.

## Methods

| SDK        | Method                     | Returns                                                  |
| ---------- | -------------------------- | -------------------------------------------------------- |
| Python     | `intents(...)`             | Single-pass iterator of typed `IntentEvent` dictionaries |
| Rust       | `intents(HistoricalQuery)` | `HistoricalStream<IntentEvent>`                          |
| TypeScript | `intents(options)`         | `Promise<IntentEvent[]>`                                 |

### Python signature

```python theme={null}
intents(source, market, from_=None, to=None, allow_gaps=False)
```

### Parameters

| Parameter        | Type                          | Required | Notes                                                                                  |
| ---------------- | ----------------------------- | -------- | -------------------------------------------------------------------------------------- |
| `source`         | string                        | Yes      | Intent data source ID, such as `uniswapx`, `lifi`, or `cowswap`                        |
| `market`         | string                        | Yes      | Use `intents` for intent and RFQ observations                                          |
| `from_` / `from` | string, date/time, or integer | No       | Inclusive start time                                                                   |
| `to`             | string, date/time, or integer | No       | Exclusive end time                                                                     |
| `allow_gaps`     | boolean                       | No       | Python and Rust only; return covered rows and warn instead of failing on coverage gaps |

## Query intent observations

<CodeGroup>
  ```python Python theme={null}
  from itertools import islice

  from polaris_data import PolarisClient

  with PolarisClient() as client:
      observations = client.intents(
          source="uniswapx",
          market="intents",
      )
      print(list(islice(observations, 2)))
  ```

  ```rust Rust theme={null}
  use futures_util::StreamExt;
  use polaris_data::{HistoricalQuery, PolarisClient};

  #[tokio::main]
  async fn main() -> Result<(), Box<dyn std::error::Error>> {
      let client = PolarisClient::builder().build()?;
      let mut observations = client
          .intents(HistoricalQuery {
              source: "uniswapx".into(),
              market: "intents".into(),
              from: None,
              to: None,
              allow_gaps: false,
              materialize_orderbooks: false,
          })
          .await?;

      while let Some(observation) = observations.next().await {
          println!("{:?}", observation?);
      }
      Ok(())
  }
  ```

  ```typescript TypeScript theme={null}
  import { PolarisClient } from "polaris-data";

  await using client = new PolarisClient();

  const observations = await client.intents({
    source: "uniswapx",
    market: "intents",
  });

  console.log(observations.slice(0, 2));
  ```
</CodeGroup>

## Observation model

Each returned row is one stored observation. The method preserves storage order
and does not combine related rows into a lifecycle snapshot. Correlate rows with
`rfq_id` and `intent_id` when you need to reconstruct a lifecycle.

For example, one row can contain an RFQ and quote:

```json theme={null}
{
  "collector_timestamp": 1704067200100,
  "collector_sequence": 1,
  "exchange_timestamp": null,
  "exchange_sequence": null,
  "source": "uniswapx",
  "market": "intents",
  "type": "intent",
  "data": {
    "rfq_id": "rfq-1",
    "requester": "0xrequester",
    "inputs": [
      {
        "asset_id": "eip155:1/erc20:0xaaa",
        "chain_id": "eip155:1",
        "amount": "100"
      }
    ],
    "outputs": [
      {
        "asset_id": "eip155:1/erc20:0xbbb",
        "chain_id": "eip155:1",
        "amount": "95",
        "recipient": "0xrecipient"
      }
    ],
    "amount_kind": "exact_input",
    "quote": {
      "quote_id": "quote-1",
      "response": [
        {
          "asset_id": "eip155:1/erc20:0xbbb",
          "amount": "97"
        }
      ],
      "solver": "solver-a"
    },
    "transactions": []
  },
  "raw": {
    "requestId": "rfq-1"
  }
}
```

A later row for the same intent can contain only the fields relevant to a
status or settlement update:

```json theme={null}
{
  "collector_timestamp": 1704067200300,
  "collector_sequence": 3,
  "exchange_timestamp": null,
  "exchange_sequence": "intent-1",
  "source": "uniswapx",
  "market": "intents",
  "type": "intent",
  "data": {
    "intent_id": "intent-1",
    "inputs": [],
    "outputs": [],
    "status": "settled",
    "transactions": [
      {
        "chain_id": "eip155:42161",
        "transaction_hash": "0xsettlement",
        "block_number": "123"
      }
    ],
    "settled_at": 1704067200250
  }
}
```

## Intent fields

The canonical payload lives under `data`:

| Field          | Type              | Meaning                                                  |
| -------------- | ----------------- | -------------------------------------------------------- |
| `rfq_id`       | string, optional  | Identifier that correlates an RFQ with its responses     |
| `intent_id`    | string, optional  | Identifier that correlates executable-intent updates     |
| `requester`    | string, optional  | Account or address that requested the quote              |
| `signer`       | string, optional  | Account or address that authorized the executable intent |
| `inputs`       | array             | Assets supplied by the requester or signer               |
| `outputs`      | array             | Assets requested or delivered                            |
| `amount_kind`  | string, optional  | `exact_input` or `exact_output`                          |
| `expires_at`   | integer, optional | Venue-provided intent expiry timestamp                   |
| `quote`        | object, optional  | Quote identifier and quoted response assets              |
| `status`       | string, optional  | Canonical execution lifecycle status                     |
| `transactions` | array             | Transactions that execute or settle the intent           |
| `settled_at`   | integer, optional | Venue-provided settlement timestamp                      |

`inputs`, `outputs`, and `transactions` are always arrays, but they can be empty
when an observation only changes part of the lifecycle.

### Asset amounts

Each object in `inputs`, `outputs`, or `quote.response` contains:

* `asset_id`: canonical asset identifier
* `chain_id`: chain identifier when the venue supplies one
* `amount`: venue amount as a string, preserving its original precision
* `recipient`: destination account or address when applicable

### Quotes and settlement transactions

* `quote.quote_id` identifies the response, and `quote.response` contains the quoted assets.
* Every settlement transaction has a `transaction_hash`; `chain_id` is optional.
* Venue-specific fields, such as a solver name or block number, remain available alongside the canonical fields.

### Status values

`status` is one of `submitted`, `open`, `partially_filled`, `executing`,
`filled`, `settled`, `cancelled`, `expired`, `failed`, or `unknown`.

## Raw venue payloads

When the standardized observation owns the exact captured upstream JSON, the
SDK returns it under `raw`. Use `data` for cross-venue analysis and `raw` when
you need venue-specific fields that are not part of the canonical model.

## How it works

The intent method filters `type: "intent"` rows from the standardized stream
using snapshot-first replay. It omits metadata and unrelated event types while
preserving the stored order of the remaining observations.

## Related documentation

* [Intents and RFQs guide](/guides/intents-and-rfqs) for lifecycle reconstruction
* [Event envelope](/concepts/event-envelope) for shared identity, timestamp, and ordering fields
* [Events](/schemas/events) for mixed standardized event streams
* [Catalog](/reference/catalog) for current source IDs and historical bounds
* [Snapshots](/reference/snapshots) for snapshot-first historical reads