Routing Recommendations
Get a Routing Recommendation
Send a payment context and your candidate providers — Yuno returns the recommended route, ranked by your own reported transaction history.
POST
Get a Routing Recommendation
This endpoint recommends which of your own provider accounts to route a payment to, based on the outcome history you send Yuno through the Transaction Reporting API. You send the payment context and the candidates you can actually use; Yuno returns the recommended candidate, a full ranking with per-candidate metrics, and a
recommendation_id.
The transaction itself never passes through Yuno. Yuno recommends; you decide and process.
Enabled per organization — this API requires activation for your organization. Contact your Key Account Manager (KAM) to enable it. Until then every call returns
403 PRODUCT_NOT_ENABLED.How it works
- You report your off-Yuno transaction outcomes through the Transaction Reporting API. Only payments with
origin: REPORTEDfeed the statistics — Yuno-processed traffic is a different population and is deliberately kept out. - Before routing a payment, you call this endpoint with the payment context and your candidate providers.
- Yuno computes statistics per candidate — approval rate, average provider latency, sample size — over a rolling 30-day window of your reported payments, segmented by provider, country and payment method (and BIN, when you send it), and returns the ranking ordered by your objective.
- You route the payment yourself and report its outcome. If the reported event carries the same
merchant_order_idyou sent here, Yuno attributes the outcome to this recommendation automatically — closing the loop without you storingrecommendation_id.
SUCCEEDED counts as approved and SUCCEEDED + DECLINED as decided. Payments in any other status (e.g. ERROR, pending) are ignored for the rate and latency, though they still count toward sample_size.
Request body
string (UUID)
required
The merchant account the recommendation is issued for. Travels in the body; Yuno promotes it to the account header internally. Must belong to the organization of the API credentials.
string
Optional merchant-supplied order reference (max 255). Stored with the issued recommendation as the correlation key for closed-loop attribution.
object
required
The payment context the recommendation is scored against.
object[]
required
The providers to rank. Between 2 and 20 items — a recommendation over a single candidate is meaningless.
enum
default:"APPROVAL_RATE"
The objective the ranking optimizes.
APPROVAL_RATE (default), LATENCY, or BALANCED.Response
string
Unique identifier of the issued recommendation. A fresh id is generated on every call.
string
Echo of the request field, when supplied;
null otherwise.enum
The objective applied to the ranking.
enum
How the ranking was decided —
MERCHANT_HISTORY or INSUFFICIENT_DATA (see below).object
The top of the ranking. Always present.
object[]
Every candidate, ordered by the objective.
Reading the response
recommendedis always present — even without enough history. You never need a special branch:decision_sourcetells you how much to trust it.decision_source: MERCHANT_HISTORY— at least one candidate reached the minimum sample; the ranking reflects real statistics over your reported payments.decision_source: INSUFFICIENT_DATA— no candidate reached the minimum sample of recent reported events. The full ranking still comes back, and the recommendation falls back to the best available data, or to request order as a last resort. Read each candidate’ssample_sizeto see how much history backs it before relying on the order.sample_sizeis the honesty of the recommendation. A high approval rate over 12 events is not the same signal as one over 12,000.- The full
rankingalways comes back, ordered by your objective. If the recommended candidate declines, take the next entry — cascade retry without a second call.
Choosing an objective
optimize_for orders the ranking: APPROVAL_RATE (default), LATENCY, or BALANCED (a weighted blend of both). There is no cost objective yet — the Reporting API does not collect fees, and Yuno does not rank on data it does not have.
Candidates are your constraint layer
The recommendation is always one of thecandidates you send — Yuno never proposes a provider you did not list. Send only the providers this payment is genuinely allowed to use (eligibility, contracts, committed volumes), and the recommendation respects those constraints by construction.
Retries
There is no idempotency header on this endpoint, and none is needed: each call computes a fresh recommendation with a newrecommendation_id, and requesting a recommendation changes no state. Retrying after a network failure is always safe.
Examples
Errors
Errors return acode and a messages array.
Authorizations
Body
application/json
Example:
"7825fc5e-e50a-4248-9ae8-5d3786afb0be"
Required array length:
2 - 20 elementsMaximum string length:
255Example:
"order_45678"
Available options:
APPROVAL_RATE, LATENCY, BALANCED Example:
"APPROVAL_RATE"
Response
OK
Example:
"3e37f0c9-e9cd-4d85-9e1a-ec5f09af296d"
Example:
"order_45678"
Available options:
APPROVAL_RATE, LATENCY, BALANCED Example:
"APPROVAL_RATE"
Available options:
MERCHANT_HISTORY, INSUFFICIENT_DATA Example:
"MERCHANT_HISTORY"
Get a Routing Recommendation