Privacy

What we hold. Which is very little.

This is a plain-language summary of what the service does with data, written by the person who operates it, checked against the code that runs. It is not legal advice, and it is not a contract. Where this page and the code disagree, the code is the bug and we will fix it.

Data controller: Brelsford Software LLC, the company behind HLA-Verify. Questions, corrections and deletion requests: hello@hlaverify.com.

Do not send patient identifiers

Send allele names and typing strings. Do not send patient records, names, dates of birth, medical record numbers or any other identifier. The service does not need them to answer, does not look for them, and does not want them.

The /v1/verify endpoint and the verify_text tool accept up to 200,000 characters of free text because typing reports and model output arrive as prose. That limit is a size cap, not an invitation to paste a chart. Strip the identifiers before you call, and send the part with the alleles in it.

Said honestly: HLA types are themselves genetic data, and a rare type in a small population can be quasi-identifying even with no name attached. Nothing you send is stored (see below), but if your policy says such data may not leave your perimeter, self-host rather than call the hosted API. The in-browser demo makes no network call at all.

What happens to a request

Request bodies are processed in memory and discarded when the response is written. There is no content log, no queue, no copy kept for debugging, and no training use: the product has no model to train.
Metering records counts, never content. Each call writes one row: the key label, the endpoint, the release the verdict was computed against, the HTTP status, whether the call was keyed or anonymous, the tier, how many units were computed and how long it took. No allele, no text, no email address is in that row.
Rate limiting uses your IP address in memory only. Anonymous calls are limited at 60 per minute per IP. The address is the limiter's key for the length of that request; it is not written to a record we keep.
Nothing is sent onward. A verification request makes no outbound call on your behalf, to an analytics vendor or to anyone else.

Cloudflare runs the network the API sits on and is a processor for it. Like any host, it sees the connection, including the IP address it arrives from, and applies its own network logging and abuse protection. We do not add a content log on top of that, and the request body is not part of what it retains for us.

The beta list

The form on /beta is the one place the service asks you for anything about yourself. Here is the whole record it writes.

Field	Where it comes from
`email`	What you typed. Required, because it is the thing we mail.
`org`	What you typed, if anything. Optional.
`use_case`	What you typed, if anything. Optional. It decides whether a hand-issued beta key makes sense.
`source`	Which form sent it, so signups from the site can be told from signups made by hand.
`ts`	The time the record was written.
`country`	The two-letter country Cloudflare reports for the connection. Not the IP address: the IP is deliberately not part of the record.

It is used for one thing. Telling you when self-serve keys open, and sending a beta key if you asked for one. No newsletter, no sequence, no drip.
It is not sold or shared. Not to advertisers, not to partners, not to anyone.
Signing up is optional. Anonymous access is open at 60 requests per minute per IP without any signup at all.
Deletion on request. Reply to any mail from us, or write to hello@hlaverify.com, and the record is deleted. You do not have to explain why, and the answer will say when it was done.

API keys, payment and sign-in

A key record holds a label, a tier, a status and the email the key was issued to. That is what lets us mail you about a release change and stop a key that was leaked. It holds no request history.
Payment is handled by Stripe. When self-serve checkout opens, card details go to Stripe and never reach our servers. What comes back to us is the email address and name Stripe reports for the purchase, plus the subscription or payment reference needed to keep the key in step with the subscription.
OAuth sign-in for the MCP endpoint carries a key, not an account. There are no user accounts. The consent screen asks for an existing API key; the code and tokens issued from it carry that key encrypted, and the MCP endpoint decrypts it and applies exactly that key's tier and limit. The client never sees the key, we store no profile, and revoking the key stops every token made from it on the next request. The only things written down are single-use markers so a code cannot be replayed, and a revocation record so a stolen refresh token can be cut off.

The website

Cloudflare Web Analytics, and nothing else. It is a measurement script served from static.cloudflareinsights.com that reports the page URL, the referring URL, page-load timings, and the browser, device type and country derived from the request. It sets no cookie, assigns no persistent visitor id, and follows nobody across other sites. There is no advertising pixel and no other analytics vendor on this site.
No cookies beyond the ones a flow needs. The site sets no tracking cookie. The only cookie the service sets at all is a short-lived one during OAuth sign-in, which exists to stop a forged consent submission and is gone when the flow ends.
The demo stays in your browser. /demo runs the engine client-side. What you type there is not sent anywhere, including to us.
Forms. The only form on the site is the beta signup above.

How long things are kept

What	How long
Request bodies and responses	Not stored. The lifetime of the request.
Metering rows (counts, no content)	Kept while the account is active, for rate limits, invoices and capacity planning.
Beta list record	Until self-serve keys have launched and you have been told, or until you ask for it to be deleted, whichever comes first.
API key record	While the key exists, plus the period the payment processor requires for billing records.
OAuth markers and cookie	Minutes to days. They expire on their own.

Asking us to do something about it

One address handles all of it: hello@hlaverify.com. It reaches the person who built the service.

See what we hold about you. Ask, and you get the record, which for most people is one beta-list row.
Have it deleted or corrected. Ask, and it is done, normally the same day.
Ask where it sits. The service runs on Cloudflare's network and data is stored in Cloudflare KV and Analytics Engine; payments, when they open, run through Stripe. If your review needs specifics beyond this page, ask and you get specifics.

If this page changes in a way that matters, the change is described here rather than slipped in. Last reviewed against the running code in September 2026.