Skip to main content
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

  1. You report your off-Yuno transaction outcomes through the Transaction Reporting API. Only payments with origin: REPORTED feed the statistics — Yuno-processed traffic is a different population and is deliberately kept out.
  2. Before routing a payment, you call this endpoint with the payment context and your candidate providers.
  3. 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.
  4. You route the payment yourself and report its outcome. If the reported event carries the same merchant_order_id you sent here, Yuno attributes the outcome to this recommendation automatically — closing the loop without you storing recommendation_id.
Only reported payments in a terminal status feed the approval rate: 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).
The top of the ranking. Always present.
object[]
Every candidate, ordered by the objective.

Reading the response

  • recommended is always present — even without enough history. You never need a special branch: decision_source tells 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’s sample_size to see how much history backs it before relying on the order.
  • sample_size is the honesty of the recommendation. A high approval rate over 12 events is not the same signal as one over 12,000.
  • The full ranking always 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 the candidates 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 new recommendation_id, and requesting a recommendation changes no state. Retrying after a network failure is always safe.

Examples

Errors

Errors return a code and a messages array.

Authorizations

PUBLIC-API-KEY
string
header
default:<Your PUBLIC-API-KEY>
required
PRIVATE-SECRET-KEY
string
header
default:<Your PRIVATE-SECRET-KEY>
required

Body

application/json
account_id
string<uuid>
required
Example:

"7825fc5e-e50a-4248-9ae8-5d3786afb0be"

payment
object
required
candidates
object[]
required
Required array length: 2 - 20 elements
merchant_order_id
string
Maximum string length: 255
Example:

"order_45678"

optimize_for
enum<string>
default:APPROVAL_RATE
Available options:
APPROVAL_RATE,
LATENCY,
BALANCED
Example:

"APPROVAL_RATE"

Response

OK

recommendation_id
string<uuid>
Example:

"3e37f0c9-e9cd-4d85-9e1a-ec5f09af296d"

merchant_order_id
string | null
Example:

"order_45678"

optimized_for
enum<string>
Available options:
APPROVAL_RATE,
LATENCY,
BALANCED
Example:

"APPROVAL_RATE"

decision_source
enum<string>
Available options:
MERCHANT_HISTORY,
INSUFFICIENT_DATA
Example:

"MERCHANT_HISTORY"

ranking
object[]