Transparency

Transparency Statement

An architectural overview for technical teams on IWKey's streaming transit mechanisms, database retention boundaries, and usage reconciliation. Legal terms and obligations remain governed exclusively by our Terms & Privacy Policy.

No bodies stored at gateway Usage queryable Schema snapshot public

Text request prompt bodies persisted at rest on success

Customer data used for training or fine-tuning

7 Days

Video output backup retention (upon request)

Per-call

Detailed billing logs exportable on demand

Lifecycle

Four Stages of an API Request

The gateway authenticates, routes, and accounts for usage. Payload content streams through memory without database persistence.

01 · Ingestion & Auth

Verify identity and route selection

Gateway Action: Verifies API key, account balance, and rate limits, selecting upstream route

Data Touched: API key and requested model name

Retention State: No request payload persisted

02 · Native Forwarding

Streaming relay and response return

Gateway Action: Sends native request to upstream provider, streaming chunks back to client

Data Touched: Prompts and completions (in-flight in memory only)

Retention State: Streamed in transit; no payload persisted at rest

03 · Accounting

Token usage accounting and deduction

Gateway Action: Deducts account balance based on upstream returned token usage or specs

Data Touched: Token count, latency, and status code

Retention State: Writes one structured billing log entry

04 · Retention Lifecycle

Metadata retention and accounting

Gateway Action: Maintains queryable usage history for reconciliation; does not store payload bodies

Data Touched: No new request data touched

Retention State: Billing metadata, statuses, and error summaries only

Retention Scope

Gateway Data Retention Matrix

Detailed breakdown of data retention status, purpose, duration, and access boundaries across IWKey.

Data Category	Retained?	Primary Purpose	Retention Period	Access Boundaries
Prompts and completions (standard successful requests)	✕ Not Retained	Streamed in-memory, released upon transit; successful requests do not write prompt or completion bodies	0 seconds	No text request payloads stored or accessible
Billing logs (model, tokens, cost, timestamp, client IP)	✓ Retained	Billing accounting, customer self-reconciliation, and abuse control	Retained during active account lifecycle for reconciliation	Account owner (console export), platform administrators
Error summaries (HTTP status codes, upstream error messages)	✓ Retained	Debugging and network troubleshooting (excluding request bodies)	Retained as needed during operational troubleshooting	Platform technical support staff
Async video task metadata (task ID, parameters, status, URLs)	✓ Retained	Task status polling, asset delivery, and refund verification on failure	Retained during task lifecycle for polling and delivery	Task submitter, platform administrators
Generated video binary files	No default copy	Upstream direct URL valid for ~24 hours; backup retained for 7 days upon request	Deleted after 7 days	Task submitter only
Uploaded reference assets (images and reference videos)	✓ Retained	Referenced during asynchronous generation and iterative workflows	Retained until user deletion or account closure	Task submitter, platform administrators
Account profile, top-up logs, and billing orders	✓ Retained	Accounting records, balance maintenance, and legal compliance	Retained per statutory and tax regulations	Account owner, finance & audit staff
Copies for model training, fine-tuning, or data resale	✕ Never Generated	We operate purely as a gateway and do not train models or resell data	Does not exist	None

Architecture

Async Long Tasks vs. Real-Time Streaming

Objective technical mechanisms and necessary data retention across different service models.

State Lifecycle

Why video tasks require parameter retention

Unlike immediate streaming for text completions, video generation is a multi-minute asynchronous workflow. The gateway must retain task IDs, generation parameters (including prompt text), execution status, and download URLs to support client polling, output downloads, and automatic refunds upon upstream failure. Text completions and image requests involve no asynchronous polling; gateway databases do not persist prompt bodies or completion text.

Transit Routing

Native forwarding to selected model providers

As a transit routing gateway, IWKey verifies authentication and accounts for usage before forwarding requests natively to official provider nodes. We perform no model remapping, downgrading, or content tampering.

Integrity

Response Authenticity & Usage Reconciliation

Deterministic engineering mechanisms guaranteeing genuine transit and billing transparency.

01 · Native Passthrough

Relay native response identifiers

We pass through official upstream response values and identifier headers (such as system_fingerprint, request_id, and HTTP headers); the gateway layer performs no model remapping, downgrading, or parameter masking.

02 · One Call, One Record

Granular call logs per invocation

Every billing event corresponds to a single structured log entry. The console supports exporting full breakdowns by model, API key, and date range for independent client-side audits.

03 · Zero Charge on Failure

Automatic refunds on exceptions

No token quota is deducted when upstream returns an error or when connections drop. Video tasks that fail or time out automatically unfreeze and return reserved balance.

Governance

Access Controls & Data Erasure

Least-privilege internal access policies and standardized data erasure procedures.

Access Control

Internal access policies & audit trails

Only authorized system administrators may access billing and error metadata for troubleshooting, and critical administrative actions are fully audited. Text completions leave no stored payload once streamed, and no viewing interfaces exist for text request bodies; asynchronous task parameters retained for reconciliation may be accessed by the submitting user and authorized administrators within their lifecycle.

Access Principle: Least privilege with strict need-to-know isolation
Operational Audit: Critical administrative actions are logged and immutably recorded

Data Erasure

Data erasure & account closure

Customers can request complete data erasure or account closure via their registered email. We verify identity and process the deletion promptly, providing formal confirmation (except for statutory accounting records as noted below).

How to Request: Email from your registered address to [email protected]
Turnaround Time: Verified and executed promptly upon identity verification
Statutory Exceptions: Financial accounting and transaction records required by law (see Terms & Privacy Policy)

Compliance

Enterprise Due Diligence & Contact

Security Inquiries

Security / Privacy / Support Channels

Email: [email protected]
Vulnerabilities: Prefix subject with [SECURITY] for priority triage
Questionnaires: Support for enterprise security vendor assessments and third-party due diligence questionnaires

Due Diligence

Compliance Audits & Schema Snapshots

Application database schemas are published in JSON (/transparency/schema.json) as an open compliance baseline demonstrating that gateway database tables contain no prompt or completion text columns. For deeper enterprise security reviews, read-only operational materials and live reconciliation are available under NDA / commercial agreements.

Page Revision History

2026-10Published data lifecycle flow and retention matrix; detailed technical boundaries for async video workflows vs. real-time streaming.
2026-05Published public database schema snapshot (/transparency/schema.json); launched bilingual transparency documentation.

Last updated: 2026-10-01