Request API Release Notes

​

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 and 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.

​

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.
• 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.

​

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.
• 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.

​

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.

​

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.
• 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.

​

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.
• 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.

​

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.

​

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.

​

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.

​

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.

​

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.

​

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.