Skip to content
SBDocs

Providers · Guides

Keep your listing healthy

Probes, success rate, whose failures count, what hands a provider back to Sushibelt, and replacing your key.

Before you start
  • A provider your team operates, or one you are claiming.
You'll end with
An endpoint that stays yours through the trial period and after.

Once you operate a provider, its health is yours. Sushibelt looks at two things: whether your endpoint passes a probe, and how many real runs succeed. During the trial period, either one can hand the provider back to Sushibelt; after it, the success rate decides how often Sushibelt picks you.

Where to look#

  • APIs, in your storefront — each provider you operate, its endpoint's host, whether it is live (Active or Inactive), its last probe (Passing, Failing or Not yet probed), and how your claim stands.
  • Customers — volume, node types and error rate across your customers.

Probes#

A probe sends your live endpoint the request a real run would send, with your key, and checks the answer the way a real run would. Probes run when you probe your claim, when you replace your key, and when you or Sushibelt probe the live provider. To probe it yourself:

Probe your live provider (browser console)TypeScript
await fetch('/api/providers/probe', {
  method: 'POST',
  headers: {
    'x-team-slug': 'YOUR_TEAM_SLUG',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    "provider_key": "YOUR_PROVIDER_KEY"
  }),
}).then((r) => r.json())

Note: during the trial period

A probe you run yourself is a check: its result shows on your APIs page, but a failure does not end your trial. A failed probe run by Sushibelt does — it hands the provider back at once.

An inconclusive probe — a submit-and-poll task that has not finished — counts as neither a pass nor a failure. If the probe could not find your key, nothing is recorded. The outcomes are listed in the probe reference.

Success rate#

During the 14-day trial#

Sushibelt hands the provider back if, counting only runs since the handover:

  • a probe run by Sushibelt fails;
  • 5 runs in a row fail on your side, however few runs there have been; or
  • fewer than 95% of your last 50 runs succeed — judged once there have been 50. With exactly 50 runs, that allows 2 failures.

What happens then is in if the provider is handed back. The reason shows on your APIs page.

After the trial#

When a customer's step does not name a provider, Sushibelt picks one of the providers that can run it, preferring those whose recent runs succeed, whose price is lower, and whose outputs customers keep. A provider with too few recent runs to judge is treated as average, not as bad. A customer who picks your provider on a step gets it regardless.

Whose failure counts#

Only failures that are your endpoint's count against you:

How a failed run is counted
FailureDescription
Server error or failed taskYour endpoint answered with a 5xx, or your task reported failure. Counts against you.
TimeoutYour endpoint, or its task, took too long. Counts against you.
Rate limit or overloadA 429 or an "overloaded" answer. Counts against you.
Key rejected or account out of creditCounts against whoever supplied the key: you, for your own key; the customer, for theirs.
Bad requestA 4xx the request itself caused. Not yours — unless it says the model no longer exists, which is Sushibelt's.
Anything elseA failure Sushibelt cannot classify counts against you.

A step Sushibelt refuses before calling you — a missing input, a required setting left empty — is not a run of your endpoint and never counts. Sushibelt's own test traffic does not count either.

What customers see#

  • A failed step shows the error, and the customer does not pay for it — so it earns you nothing.
  • If the provider is handed back, customers see “Sold by Sushibelt” again and pay Sushibelt's price.

Keep your key current#

  1. Open your storefront's APIs page. Each provider you operate has a box headed replace the key we call it with.
  2. Paste the new key into New API key and select Replace key. Sushibelt first sends one real request to your live endpoint with the new key.
  3. Only if that passes is the new key saved; the next run uses it. If it fails, or does not finish in time, the old key stays in use and the page says why.

This needs a team owner or admin. A failed test of a new key does not count as a failed probe of your provider.

Next steps