Estimates

Global Account › Guides

Estimates only calculate. They create no order, freeze no funds, and have no quote_id. The execution price is fixed at dispatch.


POST /v1/remit/quotes

No order, no frozen funds, no database writes, and no idempotency key. This is a pure read and calculation, which you can call repeatedly as the user types.

⚠⚠ There is no quote_id and no quote expiry.

This endpoint does not return a credential for order creation; POST /v1/remittances does not accept one either.

The price is recalculated when the order is placed.

Do not design this flow as quote → lock price → order with quote_id. This product does not work that way.

(Internal exchange does lock prices; see Internal Exchange.)

Two Directions: Choose One

You provide	We calculate
`payout_amount` (what the payee receives)	`customer_total` (what the member pays)
`source_amount` (what the member spends)	`payout_amount` (calculated in reverse)

Supplying both or neither returns 400. Silently choosing one would appear to ignore the other amount.

Reverse calculation guarantees that recalculating forward produces a customer_total ≤ your supplied amount by rounding down at each step. The opposite would charge more without consent.

Important: `indicative_rate` and `applied_rate` Are Different

Field	Meaning	Audience
`indicative_rate`	Current upstream rate	For later analysis
`applied_rate`	Rate actually used to calculate the payout	Show this to the user

⚠ Using only indicative_rate makes it impossible to derive the payout from the figures shown in your UI.

A 2026-08-10 test found a 2.37% difference that appeared in none of the fee items.

Users may believe you are applying an undisclosed markup.

Neither is the execution price. That is determined at dispatch, subject to the user's slippage cap.

An Unavailable Rate Returns 200, Not 5xx

rate_available: false and reason explain why. Fees are still returned because they can be calculated locally.

Mark the rate unavailable and render the remaining fields normally. Hiding everything would suggest that the whole feature is broken.

The three reason values require different handling:

`reason`	Meaning	Suggested message
`remit_settlement_unconfigured`	A configuration problem on our side	Waiting alone will not resolve it
`remit_rate_unavailable`	Rate temporarily unavailable upstream	Try again later
`remit_amount_too_small`	Accompanied by `amount_too_small: true`	Amount too small; change it—not Try again later

We Determine `below_min`; Do Not Recalculate It

Although you have min_amount, the actual test uses the payout grid. You cannot reproduce it without the fees, haircut, and reference exchange rate.

⚠ A local comparison can block a user entering I pay 10 USDT when the minimum is exactly 10,

because round-trip quantization falls on the boundary. The rejection would come from your own interface.

Two Echoed Fields Identify the Corresponding Input

The response echoes line and your supplied-side amount (source_amount) unchanged.

⚠ Use them to determine whether a response matches the current input:

responses do not necessarily arrive in request order.

In reverse calculation there is no alternative comparison: the resulting payout naturally differs from the source the user entered,

and customer_total is only ≤ the input, not necessarily equal. Comparing those values never matches reliably,

leaving the interface stuck on Updating.

Fee Details Are for You, Not Necessarily the End User

Quoted fees are what you owe us. You determine what to charge members through retail pricing in the merchant portal; the difference is your gross profit.

You decide which figures to show your users, but do not present our wholesale price as the user's actual payment.