Provider & Model Verification

What the marketplace checks before and while a seller serves traffic, what those checks establish, and which controls are available when stronger assurance is required.

The marketplace verifies reachability, credentials, model mapping, and operational health, and enforces model identity on providers that echo a comparable id. It does not perform cryptographic attestation that a given set of weights produced a response. No such mechanism exists today.

Listing-Time Checks

Every offer created through the seller API clears all of these before it exists, on both the single and bulk create paths.

Host allowlist and SSRF guard. A seller's base URL must match a curated provider host, and the host as written must not be a private destination: loopback, 0.0.0.0/8, RFC1918, link-local, CGNAT, IPv6 unique-local and link-local, IPv4-mapped IPv6, and internal TLDs are refused. This is a static check on the URL string rather than a DNS resolution, so it does not defend against DNS rebinding.

GET /v1/providers lists the curated providers the dashboard offers, which is the practical list for a buyer:

curl -s https://api.surplusintelligence.ai/v1/providers | jq '.data[] | {id, host, trusted}'

The enforced allowlist is a superset of that set. It also carries regional Bedrock hosts and any provider onboarded through AppConfig without a deploy, so a host absent from /v1/providers is not necessarily absent from routing.

Credential validation. The submitted key is checked against the shape the provider family requires before any network call.

Live probe against the model. The marketplace sends a real, minimal request to the seller's host, with the seller's own credential, for the provider-specific model id that the canonical marketplace model maps to, over the wire that offer will be served on. A failed probe means no offer is created. The single-offer endpoint reports this as provider_probe_failed; the bulk endpoint streams a per-row status: "test_failed" inside a 200 instead, so bulk automation must branch on the row status rather than on an error code.

Media offers are probed without running a paid generation. A video offer on a known async-video host is probed against a free authenticated account endpoint (Venice GET /api_keys/rate_limits, Uncensored GET /billing/balance), which additionally demotes a key that authenticates but cannot pay. Every other media offer falls back to a GET /models liveness check. Quote endpoints are deliberately not used: they answer 200 to a bogus key and cannot distinguish a live credential from a dead one.

Uniqueness. A credential may back only one active offer per base URL and model; a second is refused with 409 duplicate_offer_for_credential. Full contract, including the bulk and rotation cases, is in Seller endpoints.

Canonical model resolution. The model name must resolve to a known marketplace model, otherwise unsupported_model on the single-offer endpoint or a per-row status: "error" in a bulk response. It is stored canonically, so an alias cannot open a second order-book entry for the same model.

Continuous Checks

Health detection and recovery. Failures are detected passively, from live buyer traffic: a failing offer is marked unhealthy and leaves the routable set. Recovery is active, because an unhealthy offer is never routed and so cannot heal on buyer traffic. A sweep runs every three minutes and restores an offer on a successful probe, with attempts backing off 1, 2, 5, 10, 30, then 60 minutes.

What that probe costs depends on the offer. For a text offer it is a small real generation capped at 16 output tokens, which consumes a little of the seller's upstream quota. For a media offer it is a GET liveness or account check that runs no generation and costs nothing. A seller can also restore an offer directly with POST /v1/seller/offers/{id}/reset-health, which clears the failure count without probing. Buyer-owned BYOK providers have no prober and recover passively on their next real request. See Health & Routing.

Credential delisting. The marketplace can delist an offer whose credential the upstream provider has confirmed invalid, so a revoked key stops absorbing routing attempts. This is dark-launched: CREDENTIAL_DELIST_MODE ships off, and until an operator arms it a confirmed-invalid credential takes the ordinary unhealthy backoff instead.

Response model identity. Where a provider echoes a model id, it is compared with the id the marketplace sent. Coverage differs by provider and by path:

• Every path, Engy. Returns 502 when the response names a different model than was requested, on the streaming path as well as the non-streaming one.
• Non-streaming only, Google (AI Studio and Vertex over the OpenAI-compatible wire). Returns 502 on a mismatch for a non-streaming reply and for one the marketplace assembled internally from a stream, but not for a true SSE passthrough, which is forwarded without an identity check. A streamed 200 is therefore not an identity assertion. Claude and Mistral on Vertex (rawPredict / streamRawPredict) are not identity-checked on any path.
• Recorded, not enforced, Concentrate. This aggregator documents silent cross-provider fallback and echoes a qualified id, so a mismatch is recorded against the request instead of failing it, and feeds seller-integrity risk scoring. That flag is internal and is not exposed on the buyer-facing request log.
• Unobservable elsewhere. Most OpenAI-compatible hosts omit model or echo whatever they were sent, leaving nothing to compare. Absence of a recorded mismatch on such a host is not evidence of a match.

Scope and Limits

Established. The endpoint is a curated provider host reachable over TLS. The seller's credential is real and worked for that model at listing time. The model name maps to a known model and a known provider-specific id. The offer is currently healthy against live traffic. On the providers and paths listed above, the response identified itself as the requested model.

Not established.

• No proof of weights. No cryptographic or semantic attestation ties a response to the advertised model. A provider silently substituting a different or modified model, on a host that echoes no comparable id, is not detected.
• No quality verification. Quantization level, context truncation, injected system prompts, and altered sampling defaults are not measured.
• Catalog metadata is asserted. Context length, modalities, and supported_parameters on a model row are mirrored from provider documentation and upstream catalogs, not independently tested.
• tee_attestation is a declared label. Some e2ee-* rows carry it in supported_features and most do not (7 of 16 on a 2026-09-07 snapshot), so the row rather than the id prefix is authoritative. Where present it is upstream-declared catalog metadata surfaced for discovery. The marketplace does not validate an enclave quote.
• Trusted status is curation. It is a judgment about who operates a host. It lowers risk; it does not prove what any single response contained.

Buyer Controls

Ordered from weakest to strongest assurance.

Two caveats on those controls.

Pinning narrows liquidity, and the failure code depends on what the pin matched. A pin matching no offer at all returns 404 no_sellers_for_model; a pin matching offers that are all unhealthy returns 503 no_healthy_sellers; a name that is not a known provider returns 400 unsupported_provider. A pin the router cannot parse at all is currently dropped rather than refused, which reopens the full order book and can serve a provider you did not ask for. ADAPTER_PIN_FAIL_CLOSED converts that into a 400 and ships off.

Two of the three minimum-discount tiers are dark-launched. X-Min-Discount and a per-key min_discount_pct floor are gated by MIN_DISCOUNT_ROUTING_ENABLED, which ships false. Until an operator arms it only the /min{N} path prefix is enforced, so do not rely on the header alone.

Route Visibility

The x-si-* route-summary headers are emitted while ROUTE_SUMMARY_HEADERS is on, which is the default, on success and on error or timeout paths alike:

Their values are closed enums and clamped integers, never provider-supplied text, so an upstream cannot inject content into them. On a streaming response they are frozen at the first byte and describe the route as of serving start. The table above is the routing subset; the same append-only contract also carries cache-affinity headers.

Two further headers are always present and are not governed by that flag:

GET /v1/requests returns the per-request log with provider family, route source, fallback usage, status, token counts, cost, and latency. The order book behind a routing decision is public: GET /api/markets/{model} lists every live offer with its provider, trusted, healthy, and available flags and its price.

Reporting a Mismatch

Email support@surplusintelligence.ai with:

• the x-request-id of one or more affected responses,
• the values of x-si-served-by, x-si-provider-family, and x-si-marketplace-attempts,
• the model requested and the timestamp with time zone,
• the basis for the suspicion: a reproducible prompt whose answer diverges from the same model elsewhere, a self-identification in the output, or a tokenizer, latency, or context-length anomaly.

Do not include an API key, a provider credential, or a prompt containing secrets. The request id alone is sufficient to retrieve the route.

See Also

• Health & Routing for how offers enter and leave the routable set.
• Models & Providers for the provider allowlist and model name resolution.
• Security & Privacy for credential storage and prompt retention.
• Media Inputs and Reasoning Controls for the two capability surfaces that vary by provider.