Privacy Policy
What we collect, why, how long we keep it, and the choices you have.
Last updated August 24, 2026 · Multigrid, Netherlands · KvK 42115387 · VAT NL005505617B30
1. Who is responsible
The controller of the personal data described here is Multigrid, a sole proprietorship (eenmanszaak) of Jelte Ludeke, KvK 42115387, VAT NL005505617B30. Contact us through the support form at multigrid.ai/contact.
We have not appointed a Data Protection Officer. Multigrid is operated by one person, and that person handles these requests.
2. What we collect
Account data: name, email, organisation and billing details. Usage data: request metadata such as model, provider, token counts, latency, cost and error codes.
Synchronous API requests: we do not log the content. Your prompt passes through to the provider and the reply passes back, and neither is written to our database: the row we keep records the model, token counts, latency, cost and error code, and nothing you sent. The single exception is the response cache described below, which stores nothing unless a request asks it to.
The response cache: off unless you switch it on, one request at a time. Send the X-Multigrid-Cache-Ttl header (or a cache.ttl field in the request body) and we store that request's reply, so that an identical repeat can be served from it instead of going upstream again. What is stored is the reply only, up to 256 KB of it; your prompt is kept as a SHA-256 hash used as the lookup key, never as text. Entries are keyed to your account and are never shared between customers. Each one is deleted when the lifetime you asked for runs out, and we cap that at 24 hours. Send no header and nothing is stored, or send a zero to say so explicitly for one request.
Batch API requests: we do store the content, because the feature cannot work otherwise. A batch is submitted now and run later, so each line is kept until it runs and each result is kept until you download it. Delete the batch when you are done with it, and both go.
Dashboard chat: we store the content, deliberately. It is a saved conversation. The messages you send, the replies you receive and any files you attach are kept until you delete the conversation or ask us to close your account.
Messages you send us: the support form in the dashboard and the contact form both write a row. It holds the address you asked us to reply to, the subject, the message itself and the request reference if you attached one. A message sent from inside the dashboard is filed against your account; a message sent without one is filed under a shared enquiries record, so the address you give us is the only thing in it that identifies you. The same text is sent onward to the mailbox we answer from, and the subject line alone to our own alerting channel; both are named in the Trust Center. Please do not paste an API key or a password into either form.
3. Why we process it, and on what legal basis
To route and bill requests, to run your account and to provide the dashboard: performance of our contract with you (GDPR Art 6(1)(b)).
To answer a message you send through the support or contact form: performance of that same contract where you are a customer (Art 6(1)(b)), and our legitimate interest in replying to somebody who has asked us a question where you are not (Art 6(1)(f)).
To detect abuse, prevent fraud and keep the platform secure: our legitimate interests in protecting the service and other customers, and in not being the vehicle for someone else's harm (Art 6(1)(f)).
To keep billing records for seven years: a legal obligation under Dutch tax law (Art 6(1)(c)).
We never process your content to train models: ours or anyone else's. There is no automated decision-making that produces legal or similarly significant effects on you.
4. Retention
Request metadata is currently retained indefinitely. There is no automatic expiry and no configurable retention window; if you need older records removed, ask through the support form and we will do it.
Saved dashboard conversations are kept until you delete them. Deleting a conversation removes its messages and attachments.
Cached responses are deleted when the lifetime you set for them runs out, which we cap at 24 hours. Deletion is on a timer rather than on your next request, so a cached reply does not outlive its window because your traffic stopped. Closing your account deletes them outright, whatever is left on the clock.
Archiving a project does not delete its request history. Those records stay so that past usage and invoices remain explicable, and closing the account does not delete them either. It strips the parts you supplied, the request metadata and tags, and leaves the counts and costs that the invoice is built from.
When we email you about a security change — a request to move your address, or a password removed by a social sign-in — the message is queued so that a mail outage cannot delete it. That queue holds the address to write to and which of the two events it was, nothing else, and rows are deleted after 14 days whether or not the message got through.
Messages you send through the support or contact form are deleted 180 days after you send them, answered or not, and a nightly sweep is what enforces that rather than anybody remembering. That covers messages sent without an account as well as messages sent from inside one. Closing your account deletes the ones sent from it at once, without waiting for that window. The copy in the mailbox we answer from is a separate store and is cleared by hand; the Trust Center names the mailbox.
Billing records are kept for seven years because Dutch tax law requires it. Everything else goes when you close the account, in the same operation rather than within a notice period, as set out in the Terms.
One thing outlives that, and it is better said than discovered. The database is backed up nightly and the last thirty copies are kept, so for up to thirty days a record deleted from the live database still exists inside them. Nothing in the product can read them and they exist only to recover the whole database after a failure, but we are telling you because restoring one would, today, bring back what it holds.
5. Sharing
Prompts are transmitted to the inference provider selected by your routing policy. Each provider's retention and training terms are published on its provider page and can be used as a routing constraint.
Our infrastructure sub-processors are listed in the Trust Center, which is the live list rather than a copy of one. Before we add another we email the address on your account and wait 30 days before anything is routed through it. There is no mailing list to subscribe to and no feed: that email and that page are the whole mechanism. Inference providers are different, because the Trust Center list of them is generated from the live configuration and one can appear the day a key for it is set; any of them can be kept out of your traffic with a routing constraint.
6. International transfers
Region pinning is not implemented. Your prompt is transmitted to whichever provider your routing preferences select, in whatever region that provider serves it from, and you should assume transfers outside the EEA occur. Each provider's own regions are listed on its provider page, and any provider can be excluded from your traffic with a routing preference: today that is the only control over where a request goes.
Where a provider is outside the EEA, the transfer relies on the European Commission's Standard Contractual Clauses in that provider's own data processing terms, or on an adequacy decision for the country concerned. We link each provider's terms from its provider page so you can check the position for the routes you actually use, rather than taking a blanket assurance from us.
7. Cookies
We set four cookies, all of them strictly necessary to provide a service you asked for. None requires consent and there is no cookie banner to click through.
mg_session identifies your signed-in session. It lasts 30 days, or until you close the browser if you did not tick “Keep me signed in”, in which case it also expires on our side after 12 hours.
mg_account records which of your accounts you are currently looking at, for people who belong to more than one. It lasts as long as your session.
mg_social is set only while you are signing in with Google or GitHub, to tie the reply from that provider back to the request that started it. It lasts 10 minutes.
mg_2fa is set only between your password and your second factor, so we know which sign-in the code belongs to. It lasts 10 minutes and is replaced by a session cookie once the code is accepted.
We do not use advertising cookies and we do not embed third-party trackers.
8. Your rights
You have the right of access, rectification, erasure, restriction, portability and objection.
Erasure is self-service: Dashboard → Settings → Danger zone closes the account and deletes your data straight away. The one thing that holds it up is money we owe you, while the account holds a cent or more of unspent credit we ask you to take the refund first, so that closing cannot quietly forfeit it. Anything smaller than a cent cannot be refunded by a card at all, and closing writes it off rather than making it a reason to keep your data.
For the other rights, ask through the support form under Dashboard → Support and we action them by hand.
We respond within one month, as GDPR Art 12(3) requires. If a request is complex we may extend that by two further months, and we will tell you within the first month if that happens.
Some data survives an erasure request: billing records are kept for seven years because Dutch tax law requires it. We will say so explicitly rather than quietly keeping them.
You may lodge a complaint with your supervisory authority; ours is the Dutch Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl).