This page isn't built on "trust us." It lays out verifiable boundaries: what we store, what we don't, and how you can check for yourself.
Whatever model the upstream returns is what we return. Key fields in the response such as id and model keep the upstream format — we don't do the trick of showing one name on the page while quietly swapping in a different model behind it.
For text and image models, the prompt / response / generated image of a successful request never enters the persistence layer. 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.
IWKey handles gateway routing, authentication, billing, and visualization — it does not train models. Your request is forwarded to the corresponding upstream; whether it is used for training depends on that upstream's own terms of service, not on IWKey repurposing it for training.
You can publicly view the schema snapshot, export 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.
What we disclose is exactly what trace the routing layer and billing layer leave behind, not a vague "we're secure."
If a promise can't be independently checked by a customer, it's closer to a slogan than a mechanism.
Pick a real call and check the id, model, timestamp, and upstream format in the response. We don't hide the real model behind an "alias wrapper," and we don't say one thing on the page while doing another in the response.
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.
After signing into the console, you can export records by model, date, and API key, then reconcile them against text tokens, video task spend, rates, and timestamps. Transparency isn't just one explainer page — it's also whether you can reconcile your own account.
What's genuinely worth writing down is usually not the most flattering part, but the exception that's easiest to leave out.
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 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.
The public paths today are /transparency and /transparency/schema.json. This isn't "opening a live database console to the public" — it's turning the boundaries that matter most and are easiest to verify into a continuously readable public asset.
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…
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 bodiesThe 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 onlyusers — Account identity Password stored as hashquota_data — Usage aggregates Numbers onlyuser_subscriptions — Subscriptions & quota cycles Quota numbers onlysubscription_orders — Recharge orders No promptstasks — Async tasks (video generation) Includes task params / promptsAsync 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.
If you find that this public page doesn't match our actual behavior, that mismatch itself is a transparency issue we treat as a priority.
[SECURITY] to the email subjectIf 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.
This page was last updated: . The public schema snapshot was generated on: --. If you find that this page's commitments don't match actual behavior, please contact us directly — that kind of mismatch is itself a problem that needs to be fixed.