01 · Model Integrity
Real models, no relabeling
Upstream responses pass through directly. Fields such as id and model keep their original upstream values — no renaming, no substitution.
Transparency
Transparency Commitment
This page documents what the gateway logs, what it never stores, and how you can verify it.
02 · Data Boundary
Successful requests store no prompts or responses
For text and image models, the prompt, response, and generated image of a successful request are not stored. Video generation retains the job_id, status, required task parameters, result URL, and billing fields needed for async task tracking, used for polling, downloads, and reconciliation.
03 · Platform Role
We handle authentication, routing, and billing
Try AI API handles gateway routing, authentication, billing, and usage reporting. Your request is forwarded to the corresponding upstream.
04 · Self Verification
Verify it yourself
You can publicly view the schema snapshot, view your own usage and billing, and check it against the model fields in responses. Contracted customers who need deeper due diligence can also request core-path explanations or patch-level read-only audits.
Boundaries
What we store, what we don't
Below is the exact list of fields our gateway and billing systems retain.
What we store
- Account identity, API key metadata, group and quota information
- Billing metadata such as model name, token counts, image generation count, video task status / duration, cost, timestamps, source IP, and request status
- For video / async tasks: task_id, polling status, result URL, failure reason, and required task parameters (including the generation prompt)
- Recharge orders, subscription cycles, balance changes, and admin operation logs
- Upstream error codes and error summaries, used for troubleshooting and reconciliation (request bodies are never persisted)
What we don't store
- Per-request prompt bodies persisted on the success path
- Per-request model response bodies persisted on the success path
- Per-request generated image bodies persisted on the success path
- Conversation history, semantic conversation summaries, attachment bodies, or file contents
- An extra copy of your request content or video results made for training or reuse
Verification
How you can verify this yourself
Three checks you can run yourself.
01
Check the native fields in the response
Send a test request and check the id, model, and timestamp in the response.
02
Check the public schema snapshot
The public path is /transparency/schema.json. You can search it directly for any prompt / response body field, or expand the highlighted tables further down this page.
03
View your own usage and billing
After signing into the console, you can filter records by model, date, and API key, then reconcile them against text tokens, video task spend, rates, and timestamps.
Limits
Boundaries and exceptions
Data retention for logs and asynchronous tasks.
Caveat
Billing logs record source IP and timestamps
Billing logs (logs) retain the source IP, timestamp, model name, and token count for every call, used for billing, risk control, and troubleshooting. These are metadata — they never include prompt or response bodies — and visibility is limited to the admin side.
Video Task Boundary
Video tasks aren't the same data shape as text completions
Video generation is an async task: we need to store the task ID, status, required parameters, billing fields, and result URL to support polling, downloads, and reconciliation. The validity period and accessibility of the result URL follow the returned URL and upstream policy; for deletion or privacy requests, please reach out from your registered email.
Current Publishing Mode
What's public today is a static explainer page + schema snapshot
What's public is two static paths — /transparency and /transparency/schema.json — not a live console into the database.
Schema
Database schema snapshot
The full snapshot is published as JSON. This page expands the tables most often questioned; see the full version at /transparency/schema.json.
Loading the public schema snapshot summary…
--application tables
--columns
--snapshot date
The current public snapshot covers customer-reachable application tables. The tables customers care about most, and that are most often misunderstood, are expanded below first.
logs — Usage & billing logs Billing summary only, no bodies
The content field stores only billing summaries (e.g. rate multipliers / token recalculation notes), never prompt or model response bodies; it also stores token counts, model name, timestamp, and source IP. Image generation requests are billed through the same table (model name, image count / quality, cost) and likewise never store the prompt or the generated image body.
tokens — User API key metadata Key metadata only
users — Account identity Password stored as hash
quota_data — Usage aggregates Numbers only
user_subscriptions — Subscriptions & quota cycles Quota numbers only
subscription_orders — Recharge orders No prompts
tasks — Async tasks (video generation) Includes task params / prompts
Async tasks such as video generation retain task parameters (including the generation prompt), status, and result URL, used for polling, downloads, and reconciliation; this is required for async tasks and is distinct from persisting successful text-completion request bodies.
Contact
Contact & appeals
Security & Privacy
Security / Privacy / Data Deletion
- Contact email:[email protected]
- Security issues:Add
[SECURITY]to the email subject - Privacy or deletion requests:Email us from your registered address so we can verify and track the request
Due Diligence
Enterprise due diligence and deeper audits
If what you need is more than this public page — a deeper vendor due-diligence review — we can provide more detailed read-only verification material under an NDA or commercial framework, such as core-path diffs, deployment boundary documentation, or supplementary answers to your specific concerns.
Last updated: 2026-09-04