Privacy Notice
Version 1.0. First published 5 August 2026.
This notice explains what personal data CYANKIWI LTD processes when you use the API at api.cyan.kiwi and the dashboard at cyan.kiwi, why, for how long, and what you can do about it.
This is a transparency notice, not a contract. It is how we meet our duty to tell you what we do with personal data. You acknowledge it when you sign in; you do not agree to it, nothing in it is a contract term, and nothing in it is, or asks for, consent to processing: every processing operation below states the legal basis it actually relies on, and none of them is consent. The contractual documents are the Terms of Service and, where we process personal data on your behalf, the Data Processing Addendum.
CYANKIWI LTD is a company registered in England and Wales, company number 16974010, registered office 64 Nile Street, International House, London N1 7SR. We are the controller for the account, billing, usage and log data described below. Data protection questions, rights requests and complaints go to privacy@cyan.kiwi. Contracts, subpoenas and formal legal notices go to legal@cyan.kiwi.
Where the processor terms live. When you send us personal data inside a prompt, you are the controller and we act for you. The terms of that processing are not a sentence in this notice, because that would not be adequate: Article 28 needs a written contract with specific clauses, and a transparency notice we can amend by posting is not that. Those terms live in the Data Processing Addendum, which forms part of your agreement with us automatically whenever that processing happens.
The short version
- Zero data retention by default. We do not write your prompts or the completions returned to you into any database, spend record or analytics store we operate. You do not have to ask for this and there is no tier where it is different.
- Two honest exceptions, both described below: an error message can contain limited request data and sits in our infrastructure logs for 30 days, and our inference engines keep an in-memory prompt cache.
- Usage metadata is retained (counts, costs, timings, model names, your account identifiers) for the periods in the table below. No message content.
- Your content is not used to train models. Not by us, and no third party receives it for training. There is no opt-in, because the capability does not exist in our pipeline.
- No advertising or analytics cookies, and no third-party tracking. Browsing the site signed out loads no fonts, scripts, images or pixels from anyone else’s servers, so nobody else learns you visited us. Signing in is the one exception you choose: it talks to Firebase Authentication, which is Google infrastructure; see “Cookies and local storage” below. There is no cookie banner because none of what we store seeks consent; what each item relies on instead is set out below.
Inference content: prompts and completions
Requests to api.cyan.kiwi/v1 are relayed as a transparent passthrough to
inference engines we operate ourselves, on serverless GPU infrastructure from
the providers on the sub-processor register. Message
content is held in memory for the request and is not written to our
datastores:
- Prompts and completions are not persisted in our request logs, our spend records, or any other datastore we operate. The spend ledger stores counts and costs only, never message content.
- Streaming responses pass straight through. We do not keep a copy.
- We do not ask for, and do not store, identifiers for your own end users, even if your client library offers a field for one.
Two things that would make “we never touch content” an overstatement, so we are not going to say it:
Error text in logs. When a request is rejected or fails, the resulting error message is written to our infrastructure logs, which are kept for 30 days, and can contain limited request data. We do not put it there deliberately and we do not read those logs looking for content; anything that lands there is deleted with the logs after 30 days.
Our prompt cache. Our inference engines keep an in-memory prompt cache.
You can see it working: the cached_tokens field in the usage object on
your response reports it, and cached input is billed at the lower cache
rate. Cached content is never written to a database or to disk.
What we store
| Data | Purpose | Retention |
|---|---|---|
| Account data: email address, account identifier, sign-in method, and for Google sign-in the display name and profile photo | Sign-in and account management | Until you close your account; deleted within one month of a verified request, except records we must keep by law |
| Contact and legal correspondence: your contact details, message, attachments and our replies when you ask a question, exercise a right, make a complaint, discuss a contract or send a formal legal notice | Answering you, handling rights requests, complaints and legal matters, and keeping evidence of how the matter was handled | Until the matter is closed, then only for as long as needed to meet a legal obligation or to establish, exercise or defend a legal claim |
| Assent records: which Terms, Acceptable Use Policy and Data Processing Addendum versions your account continued past, when, and by which sign-in method | Evidence of the agreement that governs your account | Life of the account, then 6 years (limitation period for contract claims) |
| API key records: key hashes, aliases, rate limits | Authentication and rate limiting | Life of the key |
| Per-request usage metadata: model, token counts, cost, request identifier, timestamps, latency, cache-hit flag, status | Billing, service metrics, abuse prevention | 400 days, then deleted automatically |
| Daily usage totals and payment records: Stripe transaction identifiers, amounts, billing email, and for each purchase or refund the brand and last four digits of the card the money moved on | Accounting and tax; the transaction feed and its CSV export | 6 years from the end of the financial year |
| Saved payment method: your Stripe customer identifier, a reference to the payment method you most recently paid with, its card brand and last four digits, and your auto-reload settings including any recent automatic-charge failures | Refunds to the original card, the saved-card display on the billing page, and auto-reload where you enable it | Until you remove the payment method on Stripe’s management page or close your account |
| Refund requests: amount requested, amount refunded, status, and the Stripe refund identifiers behind them | Processing self-serve refunds and enforcing their limits | 6 years from the end of the financial year, with the payment records above |
| Infrastructure request logs: source IP address, user agent, HTTP method, path, status, timing, and error messages. No request or response bodies. | Operations and security | 30 days |
We never see or store full card numbers. Card details go straight to Stripe: when you pay at checkout, Stripe saves the payment method for future use, and what we keep is a reference to it plus its brand and last four digits, which appear on your billing page, in the transaction feed and in the CSV export. Saved payment methods are managed or removed on Stripe’s own management page, linked from the billing page.
The 400-day period is enforced automatically. Account deletion is handled on request: see “Your rights” below.
Usage metadata is what you see in your dashboard, and it is the source of the public per-model service metrics. Those metrics publish whole-service aggregates only. What is published contains no message content and identifies no individual customer or individual request.
Why we process it
Under UK GDPR and, where it applies to you, EU GDPR, we rely on:
- Performance of a contract for account management, API keys, billing and support.
- Legitimate interests for service security, abuse prevention, capacity planning, aggregated service metrics, keeping assent records, answering questions and keeping evidence needed to establish, exercise or defend legal claims. We have weighed those interests against yours, and you can object at any time using the data protection contact above.
- Legal obligation for accounting and tax records, responding to data protection rights requests and complaints, handling legal process where the law requires it, and making required disclosures.
We do not rely on consent for anything, and we do not make decisions about you by automated means that produce a legal or similarly significant effect.
Do you have to provide this data? You are under no statutory obligation to provide us with any of it. Providing an email address is a contractual requirement: without one we cannot open or operate your account. Payment details go to Stripe, not to us, and are needed only if you buy Credits. Everything else in the table is generated by your use of the Service rather than asked of you. The only consequence of not providing data is that the thing it supports, the account or the purchase, does not happen.
Data protection officer. We have assessed Article 37 and concluded that we are not required to appoint a data protection officer: our core activity is relaying inference requests without monitoring the individuals behind them (the architecture is built not to), and we do not process special category data at scale. We keep that assessment under review. Data protection questions go to privacy@cyan.kiwi.
Who we share it with
Our sub-processors and service providers. RunPod provides serverless GPU workers and Modal provides managed inference endpoints on serverless GPUs; Google Cloud and Firebase provide hosting, authentication, databases and logs; Google Workspace provides business email. Stripe processes payments on our instructions, and for its own fraud and anti-money-laundering purposes acts as a controller in its own right rather than for us. Hugging Face is not a sub-processor: the model registry is read FROM its public pages, and nothing personal flows to it. Who they are, what each receives, in which role, and where it is processed is at the sub-processor register, along with the notice customers get before that list changes.
Authorities, where the law requires it. We may disclose account and usage data to law enforcement, regulators, sanctions authorities, child protection bodies and courts where we are legally required to, or where it is necessary to report or prevent serious harm. Because we do not store message content, what we can hand over is account and usage metadata and, for 30 days, the error text described above.
A buyer, if the business is sold or reorganised, subject to this notice continuing to apply.
We do not sell personal data and we do not share it for cross-context behavioural advertising. Since we set no advertising or analytics cookies and run no cross-site tracking, a Global Privacy Control signal has nothing to switch off; we honour it as an objection to any processing it does reach.
International transfers
We are a UK company. For our platform and business email we contract with Google Cloud EMEA Limited, an Irish entity that engages its US parent as a sub-processor. Platform Account Data held by it is stored in the United States, and email correspondence is processed on Google’s global infrastructure as recorded on the sub-processor register. Inference runs on serverless GPU infrastructure from RunPod, Inc. and Modal Labs, Inc., both United States companies we contract with directly; the datacenters and regions, all in the United States, are recorded on the sub-processor register, which is the canonical statement of who processes what, where.
The European Commission renewed its adequacy decisions for the UK on 19 December 2025, running to 27 December 2031, so personal data can reach us from the EEA without extra safeguards while that stands.
For onward transfers to our providers we rely, per recipient: on that recipient’s active certification under the EU-US Data Privacy Framework and its UK Extension where it holds one, and otherwise on the UK Addendum to the EU Standard Contractual Clauses, or the EU Standard Contractual Clauses for EEA-origin data. We check the mechanism per recipient rather than assuming one covers all of them; the per-recipient position is on the sub-processor register. Ask privacy@cyan.kiwi if you need more for a particular provider.
Security
Our security posture is described at the Trust Center. The binding security measures we commit to as a processor are Annex III of the Data Processing Addendum.
If we suffer a personal data breach we notify the Information Commissioner’s Office within 72 hours where feasible and the law requires it, and we tell affected people without undue delay where the breach is likely to result in a high risk to them. Where we process data on a customer’s behalf, our notice obligations to that customer are in the Data Processing Addendum.
Your rights
You can ask us for access to the personal data we hold about you, for correction, for deletion, for a portable copy, and you can object to or ask us to restrict processing based on legitimate interests. Email privacy@cyan.kiwi and we will respond within one month or, where a request is complex or requests are numerous, within up to three months, telling you within the first month that we need the extension and why, as the law allows.
Closing your account. Email privacy@cyan.kiwi from the address your account uses, or confirm the request from that address if you write from another one. That is what we mean by a verified request. We then delete your data across our authentication, key and billing systems within one month, keeping only the records in the table above for their stated periods.
Deletion is performed on request, and the one month is the commitment.
Complaints. If you are unhappy with how we handle your data, email privacy@cyan.kiwi. We will acknowledge your complaint within 30 days of receiving it, take appropriate steps to investigate what happened, keep you informed of progress, and tell you the outcome. You can also complain to the Information Commissioner’s Office at ico.org.uk, or to your own supervisory authority; the ICO normally expects you to have complained to us first and given us 45 days.
EU representative
We have not designated a representative in the European Union. We consider that we are not offering goods or services to individuals in the EU, or monitoring their behaviour there, within the meaning of Article 3(2) of the EU GDPR. That assessment covers both of our roles: as a controller, the Service is sold to businesses and we do not target individuals in the Union; and as a processor for customers, the Content Data we process is processed on the customer’s instructions: the offer of services in it, if any, is the customer’s offer to their own users, not ours. We keep this assessment under review and will appoint a representative, and name them here, if it changes.
Cookies and local storage
We set no advertising, analytics or third-party cookies, anywhere. We run no tag manager and no analytics product, and browsing the site signed out loads no fonts, scripts, images or pixels from anyone else’s servers, so visiting us does not disclose your visit to a third party.
One deliberate exception, and it is one you choose: signing in. Every sign-in path talks to Firebase Authentication, which runs on Google’s identity infrastructure: completing a sign-in, and refreshing your session on later dashboard visits, sends requests to Google from your browser. That is what using Firebase Authentication means, and Firebase is a disclosed provider on the sub-processor register. What is specific to choosing “Sign in with Google” is the Google-account OAuth interaction itself; the email link avoids that interaction, not Google’s involvement.
UK law (PECR) regulates storing anything on your device, so here is each item we store and where it stands:
- Sign-in state, kept by Firebase Authentication. Strictly necessary to keep you signed in to the dashboard you asked to sign in to. Exempt from consent.
- The email address you typed for a sign-in link, stored so the link you requested works when you open it, and deleted the moment the sign-in completes. Strictly necessary to the thing you asked for. Exempt from consent.
- Cached copies of public catalog data: model lists, serving ids and public download counts. These exist only so pages render instantly on a repeat visit; the site works without them. That is a performance cache, and we are not going to call it “strictly necessary”, because it is not. We rely instead on the statutory exception for storage that improves the appearance or functioning of a service (in force since 5 February 2026), which requires exactly two things of us: telling you clearly, which is this paragraph, and giving you a simple, free way to object. To object, block or clear site data for cyan.kiwi in your browser: clearing removes the cache, blocking stops it being written at all, and the site is built to tolerate blocked storage: every page works, it just fetches on each visit.
None of these items identifies or tracks you, and none of them seeks consent: the first two are exempt as strictly necessary, and the cache stands on the appearance-and-functioning exception with the information and objection route above.
Children
The Service is sold for business use and is not directed at children. You must be at least 18 to hold an account, and we do not knowingly collect personal data from children as account holders.
That statement is about our customers. It is not a claim about content: prompts customers send us may contain other people’s personal data, including children’s, and the customer is the controller of that data and responsible for the basis on which it is sent.
Changes
We publish changes here with a new version number and effective date. This notice is not part of the agreement, so changing it never changes your contract; it changes only the description of what we do. Where a change describes a material change to the processing itself, we will flag it prominently here, and any processing that needs a contractual footing will get one through the Terms of Service or the Data Processing Addendum change mechanisms rather than through this notice.