Policy Scope
This Data Policy explains the operating principles used for Token API and Token Factory. It supplements the Privacy Policy and Enterprise Terms of Service but is not a substitute for an Enterprise Agreement or data-processing agreement.
Product-specific commitments concerning models, providers, regions, retention, security, service access, and deletion are confirmed during enterprise onboarding and documented for the approved service.
Token API Data Path
For Token API, Customer Content is received through the approved interface and may be transmitted through TokenWay infrastructure to an approved upstream service or model provider for inference. The resulting Output is returned through the approved interface.
Service metadata may be generated for authentication, routing, metering, reliability, security, support, and compliance. Depending on the approved feature, processing may also involve temporary queues, caches, uploaded files, or operational logs.
Routing and Provider Variation
Models can use different routes and providers. Processing region, feature storage, retention, and training position can therefore vary by approved model and configuration. TokenWay does not represent a universal zero-retention or single-region default.
Where routing among approved providers is enabled, provider selection may depend on the approved model, region, availability, capacity, performance, security, or customer configuration. A requirement to pin a provider, region, or data practice must be stated in the Enterprise Agreement.
Token Factory Data Boundary
Token Factory is designed for an approved customer-controlled cloud, data center, network, or other environment. The project agreement defines who controls infrastructure, credentials, logs, backups, monitoring, administrative access, deletion, and incident response.
A customer-controlled deployment does not by itself mean that TokenWay has no operational access. Any support or administrative access is documented and limited to the approved operating model.
If a Token Factory deployment connects to external model, artifact, monitoring, identity, or support services, those data paths are identified in the project scope.
Purpose and Minimization
Data collection and access should be tied to the approved workload and service purpose. Architecture, logging, and support choices are scoped to avoid processing Customer Content that is not needed for delivery, security, reliability, or compliance.
Where practical, operational telemetry should use metadata, aggregate measures, or redacted information instead of full Customer Content.
Access and Operational Controls
The approved service defines Authorized Users, administrative roles, service credentials, quotas, environment separation, support access, and operating responsibilities.
Access should follow least-privilege principles and be reviewed when roles, services, integrations, or support arrangements change. Customers remain responsible for access within systems they control.
Logging and Observability
Metrics, logs, and traces may be used to measure availability, latency, capacity, usage, security, errors, and service health. The Enterprise Agreement or service documentation identifies material content-logging behavior for the approved configuration.
Troubleshooting that requires access to Customer Content should be authorized, limited to the relevant issue, and handled under the applicable confidentiality and data-processing terms.
Retention and Deletion
Retention differs by product, model, provider, feature, and deployment. TokenWay does not publish one fixed period as though it applies to every Token API route and Token Factory environment.
The applicable service scope or data-processing agreement defines relevant retention and deletion requirements for Customer Content, uploaded files, request metadata, operational logs, backups, and support records. Legal holds, security investigations, and mandatory records may be retained where permitted or required.
No Training by TokenWay
TokenWay does not use Customer Content to train, fine-tune, evaluate, or benchmark models unless the customer expressly authorizes that use in writing.
An upstream provider's independent retention and training position is confirmed for the approved Token API configuration. TokenWay's policy does not alter a provider's terms or practices.
Security and Incidents
The service uses administrative, technical, and organizational measures appropriate to the approved architecture and risk. Responsibilities for network security, credentials, patching, backups, monitoring, incident response, and notification are divided in the Enterprise Agreement.
A suspected security incident should be reported through the support or security channel identified for the service. TokenWay and the customer will coordinate as required by the Enterprise Agreement and applicable law.
Customer Responsibilities
Customers must not submit sensitive, regulated, or restricted data until the relevant model, region, retention, security, and contractual configuration has been approved.
Customers are responsible for lawful instructions, required notices and consents, Authorized User behavior, downstream applications, data classification, credential protection, and controls within customer-managed environments.
Customers should evaluate Outputs and maintain appropriate qualified human review for regulated, safety-critical, or consequential uses.
Contractual Scope
This Policy states general operating principles rather than a universal service commitment. The Enterprise Agreement, service schedule, statement of work, data-processing agreement, and approved technical documentation establish binding requirements for a particular customer and deployment.
Questions about a proposed data boundary or approved configuration may be sent through the enterprise inquiry process. Privacy and data-subject requests may be sent to privacy@tokenway.ai.