Legal
Privacy Policy
This policy explains what sub2tok collects while you use the platform, why, how we use and protect it, and what rights you have over it. The most important part first: the gateway does not store the bodies of your requests or responses.
Effective 2026-10-22
01Scope and controller
This policy covers the website, console and API gateway of sub2tok (the “Service”). The Service is provided by an entity registered in the Republic of Singapore (“we” or “us”). We are subject to Singapore's Personal Data Protection Act 2012 (PDPA) and are responsible as the data controller for the processing of personal information described in this policy.
This policy does not cover the independent processing of your information by upstream model providers, social sign-in providers, Alipay or blockchain networks. Please refer to their own privacy policies.
02What we collect
We collect only the information needed to run the Service:
- Account data: display name, email address, an irreversible hash of your password, email verification status, invite code, account status (role, and whether and why it is banned), and the version of the terms you accepted at sign-up and when you accepted it. To stop the same inbox from signing up again under an alias, we also keep a normalized form of your email address. If you sign in with Google or GitHub, this also includes the account identifier, email address, avatar URL and authorization tokens (stored encrypted) returned by the provider. We also keep whether you unsubscribed from notice emails, and the subject, send time and delivery outcome of each notice email we sent you.
- Session data: the session token, the IP address and User-Agent recorded at sign-in, and the session expiry, used to keep you signed in. Sign-in, sign-up and other authentication endpoints also count requests per source IP address for rate limiting.
- API token data: token name, SHA-256 hash, the first 11 characters of the token in plaintext, status, creation time and time of last call. Plaintext tokens are never stored and cannot be recovered. When you sign in with the install script, the script reports the name of your computer, which becomes part of the name of the token it creates; while the sign-in waits for your approval, we also keep the country or region it came from and show it on the approval page so you can check it.
- Usage data: request ID, upstream request ID, your account and the token used, model name, input, output and cache read/write token counts, cost and price ratio, channel, queueing time and timestamp, the raw usage fields returned by the upstream, and whether the upstream refused the request under its usage policy and, if so, in which category.
- Failure data: failure code, HTTP status, your account and the token used, model, channel, time, the API format you called and the User-Agent your client sent, and the error text returned by the upstream (flattened to one line, at most 512 characters). Upstream error text sometimes quotes parts of the request.
- Balance data: your balance and ledger entries (deposits, charges, signup bonuses, admin credits, referral bonuses, revenue share, reversals) with the corresponding usage event identifiers; how much of your balance is unspent deposits and unspent revenue share; your referral relationship (who invited you and whom you invited) and the record of each referral bonus paid; for each revenue share, the usage it came from, the subscription and the user who paid. For each deposit order we also keep a SHA-256 hash of the network address it was placed from (IPv6 by /64 block), used only to limit how many orders one network can hold at once; the address itself is not stored. For an Alipay deposit order we keep the order number, the dollar amount, the yuan price and amount, and ZPay's trade number, but not your Alipay account.
- On-chain data: the sending address, receiving address, amount, block and transaction hash of every transfer into our receiving addresses, including transfers that match no order. We compare the sending addresses an inviter and an invitee use for their deposits to identify suspected self-referrals. This data is publicly visible on the blockchain by design.
- Sharer data: if you connect an idle subscription, also its provider, upstream account email, authorization credentials (stored encrypted), node, sharing windows and time zone, the share of quota kept for you, plan, quota readings, reported models, whether paid usage is turned on and whether and when you allowed it, and the state of the upstream's training and data collection settings.
- Technical logs: server logs containing the time, account and token identifiers, channel, model, usage, cost, status code and latency, with no request body and no IP address. Nodes also keep local logs of request paths, request IDs and error messages.
- Page errors and visit statistics: when a page fails in your browser, we receive the error message, stack trace, route template of the failing page and the browser User-Agent, with URL query parameters, tokens, email addresses and IP addresses removed before logging. Page visits and load performance are measured by Cloudflare Web Analytics, which uses no cookies and does not record URL query parameters.
Beyond the above, we do not collect identity documents, biometric data, precise location or contact lists, and we do not buy personal information about you from data brokers.
03Request and response bodies
The gateway relays requests and responses in memory: request bodies reach the upstream through our nodes, converted between compatible formats where needed, and responses are streamed back chunk by chunk. We do not write your prompts, model output, files or images to a database or to persistent logs.
Usage events hold only the counts and metadata needed for metering (see Usage data in section 02), never any body content. We do not use the content of your requests to train or improve any model.
To keep a conversation on the same upstream channel as far as possible and reuse the upstream's prompt cache, when your client sends no session identifier the gateway uses a SHA-256 digest of the system prompt and the first message as the session key. It stores that key in the database with the model and the chosen channel, and deletes it about 1 hour after it was last used. The digest cannot be turned back into the original text.
Your request may be sent through a subscription shared by another user. The sharer cannot see who you are or what you sent. Before forwarding, the gateway replaces the session and installation identifiers your client sends, so the upstream sees only identifiers derived for that subscription.
When an upstream refuses your request under its usage policy, we record the number and category of refusals, not the body. An account with many refusals over a period is automatically served only from our own supply and subscriptions it shares itself. This changes only where its requests are served from; it does not ban the account.
Please note that the upstream model provider still receives the request body and handles it under its own policy. Whether, and for how long, it retains that data is the upstream provider's decision, and we cannot make any promise on its behalf. Do not include in your requests any personal information, especially sensitive personal information, that you would not want an upstream provider to process.
When an upstream returns an error, its text is stored with the failure data (see section 02), and the node's local log records the error message as well; either may quote parts of the request. We do not deliberately log request bodies.
04Why we process your information, and on what basis
We process your information on the following bases:
- Performance of a contract: creating and maintaining your account, authentication, relaying requests, metering and billing, crediting deposits, referral bonuses and subscription sharing, and emailing you about changes to the service and these terms (every such email lets you unsubscribe).
- Legitimate interests: preventing fraud and abuse (including identifying suspected self-referrals, limiting where requests are served from based on policy refusals, and tracing what caused a shared subscription to be locked out by the upstream), protecting system security and capacity, troubleshooting, and improving service quality. We weigh the impact on your rights and limit the processing to what is necessary.
- Legal obligations: meeting tax, anti-money-laundering, sanctions compliance and judicial assistance requirements.
- Consent: you agree to this policy when you sign up, and give separate authorization on the relevant page when you choose social sign-in or connect an idle subscription. You can withdraw your consent at any time. Withdrawal does not affect the lawfulness of processing carried out before it, but we may then be unable to keep providing the related service.
07International transfers
Our database is in Singapore, the site and gateway run on Cloudflare's global network, and node machines and upstream providers may be located in other countries or regions. Using the Service means your information will be transferred for processing outside the country or region where you are.
For these international transfers, we use measures such as encryption in transit, data minimization and contractual safeguards to keep protection at least at the level this policy requires.
08How long we keep your information
Account and identity data is kept for as long as the account exists. After closure, we delete or anonymize information that identifies you within 30 days, unless the law requires otherwise or we need it to handle a dispute. If an account's email address is still unverified 7 days after sign-up, we delete the account and everything entered at sign-up.
Usage records and ledger entries are financial records. For reconciliation, audit and tax compliance, we keep them for at least 5 years from creation, and during that time they may remain linked to a closed account through an anonymized identifier. The upstream error text in failure data is cleared after 30 days; the remaining fields are used to count policy refusals and are deleted after 365 days.
Session records and short-lived credentials for email verification, social sign-in, install script sign-in codes (including the computer name and country or region) and the like are deleted once they expire. Authentication rate-limit counters (including the source IP address) are deleted after a day without use. Session keys used for session affinity are deleted about 1 hour after last use. The network address hash on a deposit order is kept only until that order's amount lock ends (about a day) and then deleted. Server technical logs are deleted after 365 days. Node local logs are rotated out by file size.
After you unlink a subscription, its subscription record (provider, upstream account email, sharer) and any lockout records are kept with your account, to trace what caused a lockout.
09How we protect your information
HTTPS is enforced across the site. Passwords are stored as irreversible hashes, and API tokens only as hashes. Upstream channel credentials and sharers' authorization credentials are encrypted with AES-256-GCM, using a key managed separately by the deployment environment and never shipped with the code. Nodes store no subscription credentials; the control plane hands them down with each request. Social sign-in tokens are stored encrypted by the authentication framework.
Our live systems hold only receiving addresses and no wallet private key that could move funds. Every change an administrator makes in the admin console is written to an append-only audit log, and the administrators' query interface is read-only and never returns any secret.
No system is perfectly secure. If a data breach occurs that may harm your rights, we will notify you and report it to the regulator within a reasonable period, as applicable law requires.
10Your rights
To the extent applicable law allows, you have the following rights over your personal information:
- Access: find out what information we hold about you and obtain a copy.
- Correction: have us correct inaccurate or incomplete information we hold about you.
- Erasure: ask us to delete information when your account is closed or the information is no longer needed, subject to the retention obligations described in How long we keep your information.
- Restriction and objection: object to processing based on legitimate interests, or ask us to restrict processing.
- Portability: receive the information you gave us in a structured, commonly used, machine-readable format.
- Withdrawal of consent: withdraw any authorization you previously gave on the basis of consent.
To exercise these rights, contact us using the details below. To protect your account, we may ask you to verify your identity. As the PDPA requires, we will respond within 30 days; if we genuinely cannot, we will first tell you how long it is likely to take. If you believe our processing breaks the law, you may complain to Singapore's Personal Data Protection Commission (PDPC) or to the supervisory authority where you live.
11Children
The Service is not offered to anyone under 18, and we do not knowingly collect their personal information. If we find such information, we will delete the related account and data as soon as possible.
12Changes to this policy
When we update this policy, we change the effective date at the top and publish the update on this page. For material changes, such as changes to the purposes of processing or to the parties we share data with, we will also notify you on the site or by email.
13Contact us
We have appointed a Data Protection Officer (DPO) under the PDPA to oversee this policy and handle inquiries. For questions about this policy or your personal information, or to make a data rights request, email contact@sub2tok.com with “DPO” in the subject line. We will reply within 30 days of receiving your email.