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

# Request API Release Notes

> Track recent updates and changes to the Request Network API

This page tracks notable changes to the Request Network v2 API.

## Recent updates

<Update label="2026-Q3" description="Wallet reconciliation, rate limits, and hardened routing">
  ### New Features

  * **Payer wallet details in reconciliation** — request status responses and payment webhook payloads include `payerAddress`, the address used to make the payment, and `payerEoaAddress`, the payer's connected wallet address. These can differ when a smart account is used. Both are `null` when unavailable. See [Query requests](/api-features/query-requests) and [Webhooks & events](/api-features/webhooks-events).
  * **List requests by wallet (optional)** — the request list endpoint (`GET /v2/request`) now accepts an optional `walletAddress` filter to scope results to a single payee wallet; omit it to list across the authenticated identity scope.
  * **Tron batch payouts** — Tron payouts can now be bundled via multicall payouts using the `tron_batch` execution kind. See [Multicall payouts](/api-features/payouts#multicall-payouts).

  ### Improvements

  * **Rate-limit SLA** — authenticated integrators (via `x-client-id`) are served at a 300 requests/min SLA, with higher tiers available on request. Limits are scoped per client ID and IP. See [Authentication](/api-reference/authentication).
  * **LiFi routing hardened** — cross-chain routing is now restricted to the Across bridge, and a circuit breaker degrades gracefully when LiFi is impaired so payments remain detectable. See [Cross-chain payments](/api-features/crosschain-payments).
</Update>

<Update label="2026-Q2 • Orchestrators" description="Fee & branding partner platform">
  ### New Features

  * **Orchestrators** — a fee and branding partner layer. Provisioned by Request Network and authenticated with an `x-orchestrator-key`, orchestrators link platform Client IDs (`POST /v2/orchestrators/client-ids` and onboarding link intents), configure orchestrator fees and per-client-ID overrides (`/v2/orchestrators/fee-configs`), and apply whitelabel branding. See [Orchestrators](/orchestrators/overview).
  * **Configurable orchestrator fee model** — basis-point rates, optional USD caps, `feeBearer` (payer/recipient), and `flow` (incoming/outgoing), resolving as per-client-ID override → orchestrator default → protocol fee. See [Orchestrator fees](/orchestrators/fees).
</Update>

<Update label="2026-Q2 • Multicall payouts" description="Bundle payouts across chains and on Tron">
  ### New Features

  * **Multicall payouts** — `POST /v2/secure-payments/multicall-payouts` combines multiple existing payout links into one hosted link settled as a single bundle. Three execution kinds: `evm_same_chain`, `evm_cross_chain` (per-child Li.Fi routing), and `tron_batch`. See [Multicall payouts](/api-features/payouts#multicall-payouts).
</Update>

<Update label="2026-Q2 • Safe & gasless" description="Safe multisig payers and gasless approvals">
  ### New Features

  * **Safe multisig payments** — pay a secure payment from an existing Gnosis Safe: request Safe-ready calldata with `isSafe=true`, execute on your Safe, and track settlement by recording `safeTxHash` on the intent endpoint (`423 Locked` while in progress). See [Safe multisig payments](/api-features/safe-multisig-payments).
  * **Gasless token approvals (EIP-2612)** — on the smart-account path, permit-enabled tokens (e.g. USDC) authorize via an off-chain signature with no separate approval transaction. See [Gasless token approvals](/api-features/secure-payment-pages#gasless-token-approvals-eip-2612).
</Update>

<Update label="2026-Q2 • Tokens & compliance" description="USDT0 and Merkle Science KYT">
  ### New Features

  * **USDT0** is supported as a payment currency (alias of USDT) on Arbitrum One, Optimism, and Polygon, and is part of the cross-chain currency set. See [Supported Chains and Currencies](/resources/supported-chains-and-currencies).
  * **Merkle Science** is available as a multi-chain KYT screening provider alongside the default Hypernative — select it with `screeningProvider` on a destination's access policy. See [Compliance-gated payments](/use-cases/compliance-gated-payments).
</Update>

<Update label="2026-Q2 • Whitelabel branding" description="Theme the Secure Payment page">
  ### New Features

  * **Whitelabel branding** for the Secure Payment page — five color tokens plus logo and legal links, set at the orchestrator level or per client ID and delivered with the secure-payment metadata. See [Whitelabel branding](/orchestrators/whitelabel-branding).
</Update>

<Update label="2026-Q2" description="Tron gas fee transparency">
  ### Improvements

  * **Tron gas fees** exposed in payment breakdowns. The `fees` array now includes Tron network gas costs (energy/bandwidth converted to TRX-equivalent USD) so payers and accountants can reconcile total spend across EVM and Tron payments uniformly.
</Update>

<Update label="2026-Q1 • Payouts" description="Tron-first payouts and secure payment links">
  ### New Features

  * **Secure payout links** — `POST /v2/secure-payments/payouts` returns a hosted URL the payer opens to send a single-recipient payment. Works on EVM and Tron. Pairs with the new `payout` flag on secure payments to distinguish incoming/outgoing flows when listing.
  * **Secure payment filtering** — `GET /v2/secure-payments` accepts filters to scope listings by request ID, payout vs incoming, and creation timestamp.
  * **Secure payments without bound destinations** — Client IDs without a bound `payeeDestinationId` can still create secure payments by supplying `requests[].destinationId` inline.
</Update>

<Update label="2026-Q1 • Tron" description="Tron network support">
  ### New Features

  * **Tron** is a first-class destination network. Wallet sign-in via TronLink/Guarda/Trust/WalletConnect-Tron, USDT and USDC TRC-20 destinations, single-recipient payments, single-recipient payouts. Network ID `tron`, chain ID `728126428`.
  * **Network fee estimation for Tron** — readiness checks return whether the payer's wallet has enough TRX, energy, and bandwidth to broadcast the transaction.
  * **Max-allowance approval pattern** for Tron USDT (which does not allow approve-from-non-zero, similar to mainnet USDT).

  ### Limitations

  * **Batch payments are EVM-only.** Tron requests with multiple `requests[]` entries return a 400 with `Batch payments are not supported for TRON networks.`. Submit single-recipient payments instead.
</Update>

<Update label="2026-Q1 • Accounting" description="Payment amount accounting">
  ### Improvements

  * **Paid / received / excess amount fields** on the Payment model and webhook payloads. `totalAmountPaid` reflects the cumulative amount across multiple inbound transactions; the API now also returns `excessAmount` when a payer overpays.
</Update>

<Update label="2026-Q1 • Calldata" description="Calldata endpoint">
  ### New Features

  * **`POST /v2/secure-payments/{token}/calldata`** generates executable transaction calldata for a secure payment after the payer has selected a chain/token. Replaces previous payment-intent flow for the calldata path.
</Update>

## Endpoint coverage today

The v2 API exposes endpoints across these resource groups (see [Endpoints (V2)](/api-reference/endpoints-overview) for the OpenAPI-driven reference):

* **Requests** (`/v2/request`) — create, query, update, get calldata
* **Payments** (`/v2/payments`) — search and reconcile
* **Payouts** (`/v2/payouts`, `/v2/payouts/batch`, `/v2/payouts/recurring`) — single, batch (EVM-only), recurring
* **Secure Payments** (`/v2/secure-payments`, `/v2/secure-payments/payouts`, `/v2/secure-payments/multicall-payouts`) — incoming, outgoing, and multicall hosted links
* **Orchestrators** (`/v2/orchestrators`) — link client IDs and configure orchestrator fees (orchestrator-key auth)
* **Currencies** (`/v2/currencies`) — supported tokens and conversion routes
* **Commerce Payments** (`/v2/commerce-payments`) — authorize/capture/void/refund (preview)
* **Payer** (`/v2/payer`) — crypto-to-fiat KYC and bank account flows
* **Journey** (`/v2/journey`) — multi-hop payment tracing
* **Client IDs** (`/v2/client-ids`) — see also auth API at `/v1/client-ids`

For client ID, webhook, and payee destination management, see the [Auth API](https://auth.request.network/open-api).

## Getting help

* 📚 [API Reference](/api-reference/authentication)
* 💬 [Discord Community](https://request.network/discord)