Privacy Policy

This is the question we are asked most, so it comes first. By default, HematToken does NOT store the prompts you send or the responses models return — not as text, fragments, summaries, or embeddings, and not as a temporary copy that survives once the request has been processed.

Request content only passes through: it is received, forwarded to the provider serving that model, the response is returned to you, and it is released from memory. No stage of that writes it to our database.

What we store for each request is a log of metadata only, for monitoring, tracing, billing, and fault diagnosis:

• request time, provider, model name, status, and status code;
• input and output token counts, estimated cost, latency;
• which gateway key and which credential were used.

This log contains not one word of your request or response content. The same is true of our internal monitoring: the logs, metrics, and traces we ship there carry none of your request content.

The first exception is the "request details" setting on the Settings page — a debugging feature you control yourself:

• it is OFF by default, and stays off if your account settings cannot be read for any technical reason;
• while it is off, no request content is stored at all;
• if you switch it on, a copy of the request and response is stored on your account — already filtered to remove values that look like credentials, and truncated if too long;
• only you can read it, through your own account's dashboard;
• what is stored is capped at the most recent 1,000 requests per account; older entries are deleted automatically every day;
• you can switch it off at any time, and doing so stops any further capture immediately.

Switch it on only while you are actually chasing a problem, and consider first whether the data you send may be stored. To delete what has already been captured before that 1,000 limit is reached, contact us.

There is one further exception, and we name it here so it does not come as a surprise: requests REFUSED by our content-policy screening. For those we keep a breach record containing the time, the category, the name of the pattern that matched, the model addressed, the excerpt of the text that triggered the match, and THE SCANNED REQUEST CONTENT — the part the screening actually read, roughly the first 16 KB of the request text, once values that look like an API key or a token have been removed. We keep it because an excerpt alone leaves nobody able to judge whether a breach really occurred, including you if you wish to dispute it. It is readable only by our operators, is used for enforcing the Terms and meeting legal obligations, and is not used for anything else. The full terms are in “Content screening and evidence of a breach” in the Terms of Service.

Bear in mind that this is about what WE store. Your request content still has to reach the provider serving the model in order to be answered, and that provider's privacy policy applies there — see the section on who data is given to.

Account data:

• your email address;
• your password, stored as a hash — we never store the original and cannot read it;
• registration time, email verification, and subscription status.

Provider credentials (BYOK):

• the provider API key or OAuth token you connect, stored encrypted;
• credentials are decrypted in memory only while a request is being processed, then discarded. A credential is never displayed in full again in the dashboard.

Your gateway keys:

• stored only in a form that cannot be reversed to the original value, plus a few leading characters so you can recognise it;
• the full value is shown exactly once, when it is created. If it is lost, we cannot recover it either — you need to create a new one.

Usage metadata, recorded for every request:

• provider, model name, status, status code, timestamp;
• input and output token counts, estimated cost, latency;
• which gateway key and which credential were used.

Payment data is processed by a third-party payment provider. We receive the transaction status and the subscription period, not your card number.

• running the service: forwarding your requests to the provider you chose, or to the provider behind a model we supply;
• showing your usage, costs, and quota in the dashboard;
• billing subscriptions, deducting balance for usage of models we supply, and applying the usage limits you set yourself;
• keeping the service secure: detecting abuse, rate-limiting, and investigating incidents;
• sending operational email — verification, password reset, and account notices.

We do not sell your data, and we do not use the content of your requests to train any model.

AI model providers (BYOK models): every request you send through the gateway is forwarded to the provider you chose, along with its content. That data is then subject to that provider's privacy policy, not this one. We suggest you read it for each provider you connect.

AI model providers (models we supply): for models we serve ourselves, we forward your request to the provider behind the scenes using our credentials. The content still reaches that provider and is subject to their privacy policy. One model may be served by several providers with requests routed automatically, so the provider that receives any given request may vary. The list of providers for each model is shown on that model's page in the dashboard.

Payment provider: to process subscription transactions and balance top-ups.

Email delivery provider: to send verification and password-reset email.

Analytics: the dashboard includes Google Analytics, which receives standard page-visit data including the address of the dashboard page you open. It does not receive the content of your requests or your credentials.

Infrastructure providers: where this service's database and servers run.

Beyond that, we only disclose data where required by law or by a lawful order from a competent authority.

We use cookies only as needed:

• a session hint — it carries only a marker that you are probably signed in, used so pages do not flicker while loading. It contains no token and is not an authentication mechanism;
• display and language preferences;
• cookies set by Google Analytics.

Your own session token is stored in the browser's local storage, not in a cookie.

Account data is kept for as long as your account is active.

Usage metadata is kept for your own history and billing.

Provider credentials are kept until you delete them from the dashboard. Deleting one takes effect immediately.

After an account is deleted, account data and credentials are deleted. Some records may be kept longer where needed for legal obligations, dispute resolution, or abuse prevention.

You have the right to request a copy of your data, to request correction of inaccurate data, and to request deletion of your account and its data.

You can revoke provider credentials and gateway keys at any time directly from the dashboard, without contacting us.

Other requests can be sent to [ISI: alamat email resmi]. We may ask you to verify your identity before we act on a request concerning personal data.

Provider credentials are stored encrypted. Passwords are stored as hashes. Gateway keys are stored in a form that cannot be reversed. Dashboard access requires a session that is re-validated on every request.

No system is completely secure. We cannot guarantee absolute security, and you are responsible for keeping your own password and gateway keys confidential.

If a security incident affects your data, we will notify you as required by applicable rules.

This service is not intended for anyone under the age of majority under the law that applies to you, and we do not knowingly collect their data.

This policy may be updated. Material changes will be notified by email or by a notice in the dashboard. The date of the last revision is shown at the top of the page.

Questions or requests concerning personal data can be sent to [ISI: alamat email resmi].