2api / under the hood
verification
& security.
listing a model is not enough.
the channel has to pass its checks.
01 / technical checks
more than a “200 ok”.
each model is checked individually. its type and seller-declared capabilities determine the test suite. open a row for details.
01channel connectionhttps / auth
we check the endpoint address and access with the submitted key. only public https addresses are allowed; local and internal addresses are blocked. the destination ip is checked when connecting, a valid tls certificate is required, and redirects are not followed.
an invalid address or key cannot establish a working channel. a /models listing alone does not prove that its models work.
02responses and streamingjson / sse
we send synthetic requests and check response structure, identifiers, finish reasons and usage. if streaming is declared, we check the event sequence, completion and usage data. we record request duration and time to first token when available.
a timeout, provider rate limit or incomplete test is not counted as a pass.
03tokens and cacheinput / output / cache
we compare usage across inputs of different lengths and outputs of a requested size. we check consistency of input, output, reasoning and available cache-read and cache-write fields. some requests are repeated to observe accounting for identical inputs. suspicious discrepancies require review.
this detects anomalies; it is not an independent meter inside the provider. a cache miss alone is not a failure.
04declared capabilitiestools / json / context
we test declared capabilities: stop sequences, json responses, json schema and tool calls. test functions are not executed. for a declared context window, we use size-limited text with control markers in different positions.
this does not validate the entire advertised context window, such as a million tokens. unknown or untested capabilities are not presented as verified.
05instructions and request isolationbehavior
we check simple instruction following and whether a control marker carries over between separate test conversations. we also check requests for a nonexistent model: the channel should not silently substitute a different one.
an instruction mismatch does not prove a system prompt is present. additional instructions declared by the seller are recorded separately and are not a ban on their own.
06embeddingsvectors
we check vector counts, indices, dimensions and valid numeric values. we compare results for repeated and different inputs. configurable dimensions are tested when declared.
valid vectors demonstrate a working format, not the model’s origin.
02 / outcome
one channel. individual decisions.
if some models pass and others do not, only approved models can be sold. a shared channel-access problem prevents its models from being approved.
eligible for publication
approval is granted automatically once all required technical checks pass. no manual confirmation is needed: the seller sets prices and publishes the model. this is technical approval, not an authenticity certificate.
review required
there is uncertainty, suspicious usage or an incomplete required test. publication remains unavailable until the issue is resolved and checks pass.
checks failed
a required technical check failed. the model cannot be sold. the seller can request another check after fixing the problem.
the seller workspace stores a report with completed checks, findings and available measurements. results apply to a specific configuration; an outdated check must not approve a changed channel.
03 / seller credentials
the database stores ciphertext.
the key is needed beyond the first test: 2api uses it to send customer requests to the channel and run recurring checks. it is therefore stored encrypted, not deleted after a single run.
- each save
- a fresh random nonce. identical keys produce different ciphertext.
- bound to a channel
- the channel id and key version are authenticated. ciphertext cannot simply be moved to another channel.
- separate secret
- the encryption key lives in the server process environment, not the channel tables. a database copy alone is not enough to decrypt it.
the server decrypts the key to send a provider request. this is not end-to-end encryption: full access to the server and its secrets can expose keys. the interface and ordinary api responses do not return the stored seller key.
04 / after publication
approval is not forever.
we recheck published models without advance notice. this helps detect changes in channel behavior and signs of substitution after initial approval. the check schedule is not public.
a background check does not itself pause sales: the model stays in the catalog and continues handling requests. restrictions are applied based on the outcome if a problem is found.
sellers consent in advance to recurring checks within the stated limits. test requests may consume supplier tokens and balance; actual cost depends on supplier rates.
05 / important limits
what verification does not promise.
we continuously improve model verification. our goal is to keep models sold under another model’s name off the 2api marketplace. this is our direction, not a claim of infallible identification today.
tests can reveal instruction mismatches or suspicious accounting. they cannot guarantee the absence of a hidden system prompt, inflated usage, provider-side data retention or future failures. seller-declared instructions and technical approval are separate facts.
privacy policysomething does not add up?
send us the channel name or request id. do not send your api keys.