Skip to main content
The Transactability Index is SELAT’s observability layer for paid endpoints. It watches what actually settles across the endpoints buyers pay, and publishes each endpoint’s Transactability Score — a reliability signal delivered on the payment challenge itself, before your agent decides whether to spend. An agent that discovers a paid API mid-task has no way to know whether the endpoint actually delivers. A score reports what SELAT has observed delivered, never a merchant’s self-assessment.
This is a Developer Preview signal. The reading guidance below is stable, but the exact field paths under selatTransactabilityIndex may change during preview. Read for meaning, not as a frozen wire contract.

​
Where it appears

Each endpoint’s score rides the inbound 402 Payment Required challenge that the SELAT Router returns to your agent, under extensions.selatTransactabilityIndex. The wire key keeps the layer’s name; the value it carries is that one endpoint’s score. Because it travels on the inbound challenge, it is present regardless of which rail the payment is ultimately routed over — both x402 and MPP-routed challenges carry it.
stats may carry one or more windows — 24h, 7d, and all. Read 24h for recency and the wider windows for sample size: all accumulates the most captured payments, so a rate there carries more evidence than the same rate over 24h. A window with no data is omitted; if none has data, stats is an empty object ({}), and lastPaid is likewise {} when the endpoint has no recorded payment.

​
What each reading means

All readings live under info.healthStatus (see the example above); the paths below are relative to it.

​
How to read it safely

Absence means no data, not bad health. An endpoint with no score has not been observed settling through SELAT — it is unmeasured, not failing. Never treat a missing signal as a negative one.
  • successRate is transport-level. It records whether a captured payment was answered with a 2xx, not whether the payload was correct, complete, or useful. An endpoint can hold a perfect rate and still return content your task cannot use.
  • paidNum is your confidence weight. A rate over a handful of captured payments carries far less evidence than the same rate over many. Read the two numbers together, never the rate alone.
  • A 5xx lastPaid.status or a low successRate describes a weak recent delivery record — the upstream captured payment and failed to deliver. A 4xx is different: the request was rejected and the upstream was never paid, so it says nothing about the endpoint’s reliability — the decision trace attributes it to the requester (yourRequests), not the endpoint. The score reports what it observed — it does not recommend an action or point you to a different endpoint. The decision stays with you.

​
Reading it today

The scores already ship. Any agent running the SELAT CLI or a SELAT plugin can read them without an account, a wallet, or a spend — discovery and probing are both free. Rank candidate endpoints for a task, at no cost:
Preview a pick’s score without paying — the dry run picks, probes, and prints the Transactability Score line:
The machine-readable block rides the inbound 402 challenge your agent receives, under extensions.selatTransactabilityIndex.info.healthStatus — an agent can read it straight off the challenge before signing. Because it rides the challenge, any HTTP client can read the score — no SELAT tooling required. A plain curl to the SELAT Router proxy returns the 402; the block travels base64-encoded in the payment-required header:
A live probe may invoke the target endpoint’s method and body. Only probe an endpoint you have already confirmed is safe to call.
Trust only router-authored scores. A selatTransactabilityIndex block is a SELAT score only when it comes from the SELAT Router (a SELAT-owned issuer). SELAT enforces this: it never fetches or exposes a merchant’s self-attested score, and the Router strips any selatTransactabilityIndex a merchant puts on its own 402. When you read the challenge yourself (the curl above), treat the block as valid only from router.selat.ai or another SELAT-owned origin — never trust a score served straight off a merchant’s endpoint.

​
As structured data

For an agent that needs to log, annotate, rank, or audit the reading, SELAT also computes it as a machine-readable decision trace (quote.transactabilityTrace) that separates failures by who caused them and never blends the network and first-party readings. See the Decision trace reference.

​
Why it exists

Counterparty risk in agent payments runs one way: the buyer pays first and finds out second. A charge that captures against an endpoint that then fails to deliver is a real loss, and it is invisible to any check made before the call. Publishing observed settlement history on the challenge moves that signal to the one moment it can still change the decision — while the agent is holding the 402 and has not yet signed.