The price versus reliability tradeoff for APIs is not settled by the lowest listed call price. Once a failed attempt triggers a retry, the buyer pays in extra calls, added latency, and recovery work before the requested outcome exists.
For an API provider, this changes the comparison you need to support. A buyer should be able to see both the charge for one attempt and the measured chance that an eligible attempt completes. Hiding either field makes the apparent bargain impossible to verify.
Price the completed outcome
A per-call price describes an attempt. The workload usually needs an outcome: one verified record, one completed transformation, or one accepted result. Those units match only when the first attempt succeeds.
A useful first estimate is expected call cost per completed outcome. Divide the price of one attempt by the observed success rate, expressed as a decimal. This is a model, not a bill. It assumes attempts have similar prices and that failures are independent and safe to retry. Still, it exposes why two prices cannot be compared without an operating measure.
The model should stay separate from result quality. A technically successful response can satisfy the published schema without being useful for the buyer's task. Apiosk does not measure result quality. The calculation also excludes staff time, downstream model turns, and the delay created by retry backoff unless the buyer adds those costs explicitly.
Providers should therefore name the commercial unit clearly. If you charge only for delivered results, say how delivery is classified. If every attempt can be charged, make that boundary visible in the live payment terms. Normalizing API pricing units is a prerequisite for comparing the resulting numbers honestly.
Separate retryable failure from final failure
Not every unsuccessful response should create another attempt. A timeout or temporary server failure may justify a bounded retry. Invalid input will usually fail again. An authorization error needs corrected credentials or payment proof. Retrying a non-idempotent operation can duplicate the underlying action even when the first response never reached the caller.
Record enough detail to make that distinction operational:
- A stable logical request or idempotency identifier.
- Candidate and endpoint identifiers for every attempt.
- Attempt price and whether the attempt was charged.
- Normalized outcome class and HTTP status when available.
- Start time, completion time, and measured duration.
- Retry number, backoff, and the rule that allowed another attempt.
- Whether one acceptable result was ultimately delivered.
These fields let the buyer group several transport attempts into one commercial outcome without erasing the failed work. They also stop a retry loop from looking like new demand. The denominator and outcome rules in API success rate measurement provide the reliability side of that record.
Compare providers under the same requirements
Price and reliability only become comparable after incompatible candidates are removed. The provider must accept the required inputs, meet any hard ceiling, and use an allowed settlement mode. A cheap endpoint that cannot consume the request is not a low-cost alternative.
Apiosk lets the buyer pass `max_price`, `max_latency_ms`, `min_reliability`, `settlement`, `require_all_inputs`, and `optimize_for` once and reuse them through discovery, comparison, and decision. Hard constraints remove candidates. The optimization preference orders the survivors.
That means `optimize_for=price` does not instruct the buyer to ignore reliability. A `min_reliability` floor can first exclude candidates below the required measured success rate. Price then ranks the eligible set. Conversely, `optimize_for=reliability` can operate inside a `max_price` ceiling.
This separation prevents a vague balanced score from overriding a non-negotiable limit. It also gives providers actionable feedback. Losing because another survivor had a lower price is different from rejection for input incompatibility or a reliability floor.
Read the score as a local comparison
`GET /v1/compare?candidates={id},{id}` places price, measured latency, measured success rate, and input compatibility side by side. Each 0-100 score is relative to the candidates in that one comparison. It is not a permanent grade for the provider.
The response carries the weights that produced the score and each candidate's contribution per dimension. A buyer can recompute the ranking and test how a different priority would change it. Choosing price, latency, or reliability explains how that preference belongs to the workload rather than the company as a whole.
Missing measurements must remain visible. When Apiosk has not measured latency or success rate for a candidate, that dimension is dropped from the weighting and named. It is not scored zero. Price, settlement rail, and input compatibility can still be returned, but the buyer should not treat absent operating evidence as proof of either good or bad reliability.
External x402 discoveries have a firmer boundary. They appear separately in `external_candidates`, have no `candidate_id`, and are unreviewed, unmeasured, and not settleable through Apiosk. They cannot enter `/v1/compare` or `/v1/decide`.
Turn comparison into a decision record
`GET /v1/decide?candidates={id},{id}` returns one provider, the rule that selected it, every rejected candidate with the exact constraint that removed it, and the runners-up in order. This record makes the price-reliability choice auditable after the call.
For each completed outcome, an operator should be able to answer which constraints were active, which measurements were available, which weights were applied, and whether a retry changed the realized cost. `POST /v1/decisions` can record the chosen provider and the rejected alternatives. The buyer can then compare the decision-time estimate with the attempts actually required.
Providers can use the same evidence without claiming universal superiority. If your endpoint repeatedly survives the reliability floor but loses on price, the commercial tradeoff is visible. If it is excluded because no reliability measurement exists, the gap is evidence coverage rather than a bad score. That is more useful than a marketplace badge with no denominator.
Where Apiosk fits
Apiosk gives agent buyers a chained way to discover, compare, and decide among reviewed API candidates. The comparison exposes price and measured operating fields under visible weights. The decision exposes the winner, exact rejections, and ordered runners-up.
For a provider, the practical role is straightforward: publish a precise callable offer, keep the input schema and live payment terms current, and let observed delivery data sit beside price. Review how to price API endpoints for agent buyers, then list your API so buyers can evaluate the cost of a completed outcome rather than a price in isolation.
Frequently asked questions
Why can a cheaper API cost more per completed request?
A failed attempt can require another paid call, add delay, and create recovery work. The relevant comparison is the expected cost of reaching a completed outcome, not only the listed price of the first attempt.
Should every failed API call be retried?
No. Retry only failures that are transient and safe to repeat. Validation errors, permanent authorization failures, and non-idempotent operations need a different recovery rule.
Does a higher Apiosk score mean a provider is always better?
No. The 0-100 score is relative to the candidates in one comparison and the weights used for that request. The response includes those weights and each candidate's contribution so the result can be recomputed.
Does Apiosk measure API result quality?
No. Apiosk does not measure result quality or provider terms. It compares returned price, settlement rail, input compatibility, and measured latency and success rate when enough proxied calls exist.