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

# Quoting and fills

> Fulfillment requirements, quote expiry, and fees for a JupiterZ V1 webhook.

This page is part of the [Webhook Integration (V1)](/docs/swap/routing/rfq/v1/overview) guide. It covers what you must meet to keep receiving quote requests, how quotes expire, and how fees work.

## Fulfillment requirements

* **Fulfillment**: fill at least **95%** of the quotes you win. Jupiter monitors your fill rate over a rolling **24-hour** window. Falling below the target does not itself suspend you: this monitor only alerts. Actual suspension comes from the [fill circuit breaker](/docs/swap/routing/rfq/v1/settlement#fill-circuit-breaker), which counts failed fills separately.
* **Response time**: respond to quote requests within **500 ms**. Slower responses are excluded from the round.
* **Uptime**: high availability is expected. Persistent 5xx errors suspend the webhook.

<Warning>
  A suspended webhook must be manually re-enabled. Reach out through the support channels on the [overview page](/docs/swap/routing/rfq/v1/overview) if this happens.
</Warning>

## Quote expiry

Quotes and transactions have a fixed expiry, so you never specify custom expiry times:

* A quote is valid for **55 seconds** from creation.
* The swap is only forwarded to your webhook while a safety buffer (currently **20 seconds**) remains before expiry, so you always have at least that long to verify, sign, and land the transaction. The time before that is the user's window to accept the quote (roughly the first 35 seconds of a 55-second quote).
* The Jupiter frontend re-quotes every 3 seconds.

These thresholds are server-configured and may be adjusted based on performance and feedback.

## Fees

JupiterZ lets you provide liquidity without being subject to on-chain gas volatility, and RFQ fills are around 10x less compute-intensive than AMM swaps. In Ultra mode, JupiterZ charges a dynamic fee selected based on factors like tokens and size; in manual mode the fee is flat.

Do not account for fees when quoting. The fee amount is forwarded to your webhook in the quote request parameters, is contained in the message both taker and maker sign, and is applied by the RFQ system during transaction building:

* For a quote of 1 SOL to 1,000 USDC with a 100 bps fee, only 990 USDC is transferred out of your account. 10 USDC is collected as the fee.
* The fee is not transferred automatically; it is accounted for asynchronously on a regular basis.
* Stable-to-stable swaps are exempt from fees.

### Non-standard payload

The fill instruction data carries a trailing metadata region that the on-chain order-engine program does not read. It exists for off-chain consumers and sits immediately after the 32 bytes the program consumes (the 8-byte instruction discriminator plus the three `u64` fill arguments). The layout is **5 bytes**:

| Bytes | Field                | Type                |
| :---- | :------------------- | :------------------ |
| 0-1   | `fee_bps`            | `u16` little-endian |
| 2     | `flags`              | `u8` bit mask       |
| 3-4   | `integrator_fee_bps` | `u16` little-endian |

The `flags` byte:

* **bit 0**: swap mode. `0` = exact-in, `1` = exact-out.
* **bit 1**: integrator fee side. `0` = input, `1` = output.
* bits 2-7: reserved.

Parse the whole 5-byte region from that offset. Reading only the last 3 bytes, or assuming a 3-byte region, gives the wrong fee and always reads exact-in.