Privacy notice

Qevra is in private development and is run by its founder as an individual; no company has been incorporated behind it yet. The registered details will appear here the moment there are any. In this notice, “we” means whoever is named in that sentence.

Qevra is sold to businesses and is not intended for children. Write to hello@qevra.dev about anything on this page.

Qevra holds two kinds of data and its responsibilities differ between them, so the rest of this notice keeps them apart.

The first is the data about you, the person who signs up: your account, your workspace, your credit. For that we decide what is collected and why, which makes us the controller.

The second is the data your product sends to the API about your own customers: the support questions, the knowledge you index, the context you attach. We hold that on your instructions and do nothing else with it, which makes us your processor and you the controller. We do not use it to train models, we do not read it to build features, and it never leaves your workspace to be seen by another.

Your account. Your name, your email address and a hash of your password. The password itself is never stored and never logged; we cannot read it or recover it for you.

Your workspace. Its name, its URL slug, and which accounts belong to it with what role.

Your sessions. When you sign in we record a session token, its expiry, and the IP address and browser user agent the sign-in came from. Sessions last thirty days.

Your API keys. A name you choose, whether the key is live or test, its prefix and last four characters, and a SHA-256 digest of the key itself. We keep no copy of the key, which is why a lost one must be replaced rather than recovered. We also record when a key was last used, at most once every five minutes.

Your billing. Every movement of credit, as an append-only ledger: the signup grant, each top-up, each answer charged, each refund. A top-up row carries the identifier of the Stripe checkout session that paid for it. No card number, expiry or security code ever reaches Qevra — those are typed on Stripe’s own page.

Knowledge you index. The title and full text of every document, the fragments it is split into, and a numeric embedding of each fragment. Whatever you choose to put in a document is stored as you sent it.

Support requests. For each call to the resolve endpoint we store the question, any context object you attached, and the identifier you use for your own end user if you send one. That identifier is opaque to us — we never learn who it refers to unless you make it something that says so.

Resolutions. The answer produced, the confidence it carried, whether it was escalated and why, the fragments it was built from, the model used, tokens consumed, cost and latency.

Feedback. Whether an answer was approved, corrected or rejected, any corrected text a reviewer wrote, and who reviewed it.

You decide what any of this contains. If your support questions carry personal data about your customers, so will our database — which is why the section on your customers’ data below matters more than any of the rest.

Qevra sets one cookie: the session cookie that keeps you signed in. It is HTTP-only, marked Secure in production, and lasts thirty days. Without it the dashboard cannot know who you are, so there is nothing to consent to and no banner to dismiss.

There is no analytics, no tag manager, no advertising pixel, no session recording and no third-party script of any kind on this site. Your choice of light or dark theme is kept in your browser’s local storage and never sent to us. We do not profile you and we take no automated decisions about you.

Your account, workspace, sessions, keys and support data are processed to perform the contract you enter into by creating a workspace. Without them there is no service to provide.

The billing ledger is kept both to perform that contract and to meet accounting and tax obligations, which is why ledger rows are never edited or deleted.

Server logs and the IP address on a session are kept on the basis of our legitimate interest in keeping the service secure and working out what went wrong when it does not.

Four providers, listed with what actually reaches each. Nothing leaves Qevra except through them.

Supabase

Managed PostgreSQL. Qevra uses it as a database only — not for authentication, storage or its REST layer.

Receives: Every record Qevra keeps: accounts, workspaces, indexed knowledge, support requests and their resolutions, and the credit ledger.

European Union — the production database runs in Frankfurt.

Vercel

Runs the application and serves the site.

Receives: Requests in transit, and the connection metadata any web server sees: IP address, user agent, and the path requested.

United States.

OpenRouter

Routes text to the models that produce embeddings and answers. Qevra talks to no model provider directly.

Receives: The text of a support question, any context object sent with it, and up to six fragments of the workspace's own indexed knowledge. Not the workspace identity, not the end-user identifier, not any Qevra account details.

United States.

Stripe

Takes payment when a workspace tops up its credit. Checkout is hosted by Stripe.

Receives: The workspace identifier and the amount. Card details are entered on Stripe's own page and never reach Qevra.

United States and Ireland.

We do not sell data, and we do not share it with anyone else — no advertisers, no data brokers, no partners. We would disclose it to a public authority only where the law required it of us.

The database sits in the European Union, in Frankfurt. Everything described above lives there.

Three of the four providers above are established in the United States, so calling the API involves a transfer outside the EU: the question and the retrieved fragments go to OpenRouter to be answered, and a top-up goes to Stripe to be paid. Those transfers rely on the standard contractual clauses each provider offers.

Plainly: indefinitely, until you ask us to delete it. There is no automatic expiry on knowledge documents, support requests or resolutions today, and we would rather say so than imply a retention schedule we have not built.

The exceptions run the other way. Sessions expire after thirty days. Ledger rows are never deleted at all, because they are the record of money moving and accounting law expects them to survive.

Deleting a workspace deletes everything hanging off it — members, keys, documents, fragments, requests, resolutions and feedback — in one cascade.

Under the GDPR you may ask for a copy of your data, ask us to correct it, ask us to delete it, ask us to restrict or stop processing it, or ask for it in a portable form. You may also withdraw consent where consent was the basis, though as set out above it generally is not.

Ask by writing to hello@qevra.dev. There is no self-service button for this yet — requests are handled by hand, within thirty days, and we will tell you when it is done rather than leaving you to check.

If you are unhappy with how we answer, you can complain to your data protection authority. In Italy that is the Garante per la protezione dei dati personali.

When your product sends us a support question, you are the controller of whatever it contains and we act only on your instructions. We use it to answer that question and to show you the result in your dashboard. We do not use it to train models, we do not pool it across workspaces, and we do not look at it except when you ask us to help with a specific problem.

If your customer asks you to delete their data, tell us and we will remove the requests and resolutions concerned. If you need a data processing agreement in place before you send us anything real, ask and we will sign one.

How the tenancy boundary, the API keys and the payment path are actually built is set out on the security page, together with an honest list of the things not yet in place.

When this notice changes materially we will update the date at the top and, if the change affects how your data is used, tell account owners by email before it takes effect.

Last updated 8 August 2026. See also the terms of service.