Claim your provider

A claim moves a provider Sushibelt already runs to you. Afterwards, customers' runs of its models go to your endpoint with your key, at your price, and your storefront sells them. Sushibelt checks four things on the way: that you control the provider's domain, that a person at Sushibelt agrees, that your endpoint answers a real request correctly, and that it can serve every model customers use today.

Can your provider be claimed?#

Find your provider's page on Sushibelt at /providers/YOUR_PROVIDER_KEY — the last part of the address is your provider key, which every claim request uses. A provider can be claimed when Sushibelt sells it (the page says Sold by Sushibelt) and reaches its API directly. A gateway — a provider that passes runs on to others, which its page describes as reselling models others make — cannot be claimed, and neither can Sushibelt's own hardware, a provider someone already operates, or one Sushibelt reaches through its own code rather than an endpoint you could declare (Fal and Replicate, today).

The website next to Runs the API on that page is the domain you will prove you control. Sushibelt records it; you cannot change it with the claim. If it is missing or wrong, contact Sushibelt before you start.

Claim in the app#

Open your storefront and choose APIs. Under Claim a provider Sushibelt runs, choose Claim next to your provider. The claim page takes you through the steps below in order, shows where your claim stands, and says what went wrong when a step does not pass. Come back to it with Continue.

The same steps as requests#

Each step is also a request you can send while signed in — the snippets below. Open Sushibelt in your browser, sign in, open the developer console on that tab, and paste the snippet. The request carries your session, and the x-team-slug header names the team you act for — the part of the app's address after the domain when you are in your team, such as acme in /acme/provider.

In every snippet, replace YOUR_TEAM_SLUG and YOUR_PROVIDER_KEY. The steps need a team owner or admin, except declaring: the price you declare is the one customers pay after the handover, so only an owner can declare.

Step 1 — File the claim#

await fetch('/api/providers/YOUR_PROVIDER_KEY/claim', {
  method: 'POST',
  headers: { 'x-team-slug': 'YOUR_TEAM_SLUG' },
}).then((r) => r.json())

The answer is 201 with the claim, its status pending, and a domain_token that starts with sbclaim_. It is the record you publish next; until your domain is proven, the claim page and GET on the claim show it again.

{
  "claim": {
    "id": "CLAIM_ID",
    "provider_key": "YOUR_PROVIDER_KEY",
    "status": "pending",
    "domain_token": "sbclaim_…",
    "created_at": "2026-09-29T10:00:00.000Z"
  }
}

• 404 This provider cannot be claimed. — the same answer for every reason: no such provider, one that cannot be claimed, or your team has no open storefront. Check the provider key and your storefront.
• 409 A claim is already open for this provider. — one claim at a time per provider, whoever filed it.

Step 2 — Publish the DNS record#

Add a DNS TXT record in either of two places. If your provider's page shows www.example.com next to Runs the API:

• _sushibelt.example.com — the label on your domain, without the www.. Your domain's own records stay as they are.
• www.example.com — the host itself, exactly as the page shows it.

Step 3 — Ask Sushibelt to check it#

await fetch('/api/providers/YOUR_PROVIDER_KEY/claim/verify', {
  method: 'POST',
  headers: { 'x-team-slug': 'YOUR_TEAM_SLUG' },
}).then((r) => r.json())

{ "verified": true, "domain_verified_at": "…" } means the record was found. Otherwise the answer is { "verified": false, "reason": "…" } and nothing changes, so fix the record, give DNS time to update, and ask again. Both places are checked, and the reason says what was found at each, separated by ;:

• no TXT records found for HOST — the record is not published yet, or not on that host.
• no TXT record at HOST matched this claim's domain token — a record is there, but its value is not exactly the token.
• DNS lookup for HOST failed — the host did not answer; check it exists.
• A reason saying the provider has no valid website — Sushibelt has not recorded one; contact Sushibelt.

404 No open claim to verify for this provider. means your team has no pending claim on it.

Step 4 — Sushibelt's approval#

Once the domain is verified, a person at Sushibelt reviews the claim. Approval moves it to verifying; a rejection moves it to rejected. Read where your claim stands at any time:

await fetch('/api/providers/YOUR_PROVIDER_KEY/claim', {
  method: 'GET',
  headers: { 'x-team-slug': 'YOUR_TEAM_SLUG' },
}).then((r) => r.json())

The answer's claim has status, rejectionReason when Sushibelt declined it, and, once there is a handover, cutoverAt, dwellUntil, and either completedAt or rolledBackAt with rollbackReason.

Step 5 — Declare your endpoint, price and key#

At verifying you tell Sushibelt three things. Nothing about the live provider changes yet: customers' runs keep going where they go today.

await fetch('/api/providers/YOUR_PROVIDER_KEY/claim/declare', {
  method: 'POST',
  headers: {
    'x-team-slug': 'YOUR_TEAM_SLUG',
    'Content-Type': 'application/json',
  },
  body: JSON.stringify({
    "transport": {
      "baseUrl": "https://api.example.com/v1"
    },
    "credits_per_unit": 2.5,
    "pricing_unit": "run",
    "credential": {
      "api_key": "YOUR_API_KEY"
    }
  }),
}).then((r) => r.json())

The answer repeats what was staged: { "declaration": { "transport": …, "credits_per_unit": 2.5, "pricing_unit": "run" } }. The transport comes back with a family field added; you can send it back as it is.

Declaring again replaces the staged declaration and clears the last probe result, so probe again after every change. If you replace the key, probe again with it too.

• 400 Invalid transport declaration with problems — each problem names a field and what it must be. See the error list.
• 400 credits_per_unit must be a number greater than 0, … at most 6 decimal places, or pricing_unit must be one of: ….
• 404 No claim in verifying for this provider. — the claim is not approved yet, or has moved on.
• 409 This claim is no longer accepting a declaration. — it changed state while you declared.

Step 6 — Probe your declaration#

await fetch('/api/providers/YOUR_PROVIDER_KEY/claim/probe', {
  method: 'POST',
  headers: { 'x-team-slug': 'YOUR_TEAM_SLUG' },
}).then((r) => r.json())

The probe sends your endpoint the same request a real run would, with your key, and reads the answer the way a real run would. It makes a real call: your API does the work and may bill your own account for it. The answer's outcome is pass, fail with an error, or inconclusive when a submit-and-poll task has not finished yet — probe again and it checks the same task. All outcomes are listed in the probe reference.

Step 7 — The handover#

With a passing probe, Sushibelt decides whether to hand the provider over. It is a second, separate decision from the approval. Before it happens, Sushibelt checks that:

• your domain is verified and the claim is approved;
• your latest declaration passed its probe, with the key you declared — a key saved after the probe needs a new probe;
• your endpoint is still on your verified domain;
• your price is in the unit your listings use, and Sushibelt can count that unit for your endpoint (see pricing units);
• your endpoint can take a request for every model customers can run on your provider today. If it cannot, the handover waits until those models have a request shape your endpoint serves, or are retired.

At the handover, in one step:

• customers' runs of your provider go to your endpoint, with your key;
• your listings read “Sold by” your storefront;
• your price applies — at once if it is not above today's price, otherwise 7 days later, with customers paying today's price until then;
• every charged step starts earning you your price;
• the 14-day trial period begins.

Step 8 — The trial period#

For 14 days after the handover, Sushibelt watches your endpoint. It hands the provider back to itself automatically if any of these happens:

• a probe of your live endpoint fails;
• 5 runs in a row fail on your side;
• fewer than 95% of your last 50 runs succeed. This is only judged once you have had 50 runs since the handover.

Only failures that are yours count — see whose failure counts. If none of this happens, the claim completes by itself when the 14 days are up, even if your provider had no runs.

Your storefront's APIs page shows how it stands: Handed over; the dwell period ends and the date, then Complete since the date, or Rolled back on the date with the reason.

If the provider is handed back#

• Customers' runs go back to the endpoint Sushibelt used before, on Sushibelt's key.
• Listings read “Sold by Sushibelt” again, at Sushibelt's price. Your declared price stops applying.
• New runs stop earning you money. What you already earned stays in your balance, and you can still request it.
• You can fix the cause and file a new claim.

After the trial period#

The handover is permanent. You can replace your key at any time (see keep your key current). Sushibelt can still return the provider to itself — for example if your API stops serving, you stop trading, or you break the seller agreement — and records why. While your team operates a provider, or has a claim open, your storefront cannot close.