Privacy

What we collect

Your email address, because you typed it into the form.

Which of the two forms you used — the one at the top of the page or the one at the bottom. That is stored as the word "hero" or "footer" and nothing else. It tells us whether people decide immediately or after reading, which is how we edit the page.

For the waitlist, that is the complete list. No name, no company, no IP address, no tracking pixel, no profile built about you, and the form itself sets no cookie. Asking for an API key is different, and the next section says exactly how. The cookies this site does set have a section of their own, below.

If you hold an API key

We store the email you signed up with, a label you choose for the key, the first few characters of the key, and a count of how many requests you made each month.

We never store the key itself — only a hash of it. That is not a slogan: if you lose the key we genuinely cannot recover it, because we do not have it. We can only issue you a new one and retire the old.

For every call that costs credits we store which key made it, which endpoint it hit, when, how many credits it cost, and whether it found anything. That record is what makes the monthly free allowance possible, and it is what lets most endpoints charge nothing when they find nothing — without it we could not tell you what you spent.

What that record does not contain is the handle you looked up. There is no column for it: we keep what you spent, not who you asked about.

When a call made with your key is refused we also store a line for that: which endpoint you asked for, when, the status we answered with, and the reason — among them a key we did not recognise, a key that was not sent at all, no credits left, a monthly spending cap on your key, an endpoint name that is not one of ours, or a request that left out the platform or the handle. It is linked to your key only while that key is active: a key that has been replaced or switched off is not matched, so its refusals are stored linked to nothing at all, exactly like a key that was never ours. It holds no IP address, no headers, nothing from the body of your request, and never the key itself or a hash of it.

That record exists so we can answer you when you ask why your calls stopped working. Without it the honest answer was that we did not know — a refusal left no trace anywhere, so "we never refused you" and "we have no record" looked identical from our side, and we would rather hold the line than guess at your expense.

Turning a key off stops it working, and the usage history stays in the database. You will not be able to read it through the API any more — a key that is off is refused there — but you can ask us for a copy by email, as with anything else we hold.

Asking us to delete your data is the other thing, and then the key row itself is deleted — the usage history goes with it in the same operation, because the database is wired that way, not because someone remembers to do it. There is no separate expiry date for it, and we would rather say that than promise one the database does not keep.

The legal basis here is different from the waitlist: holding your email is part of performing our contract with you, not consent. We keep it until the key is deleted — turning the key off does not remove it. Asking us to delete it means deleting the key, and we will say so rather than quietly doing one and not the other.

If you reached us through one of our ads or a campaign link, the address carried campaign tags (utm_source, utm_medium, utm_campaign, utm_term). When you then ask for a key, those four are stored on the key itself, next to your email, along with which product page you came from. They tell us which campaign brought a signup — nothing about you, and nothing we use to decide anything about your account.

Between arriving and asking for a key, those tags sit in your browser's tab storage — not in a cookie. Closing the tab discards them.

They are kept for as long as the key exists, and are deleted with it. Turning a key off does not remove them, in the same way it does not remove your email.

When you ask for a key — or ask us to replace one you lost — we record the IP address the request came from, the time, and which of the two you asked for. To recognise a repeat address we also keep your email in a normalised form next to it.

Normalised means: everything lower-cased, and anything from a + onwards in the part before the @ is dropped. For Gmail and Googlemail addresses the dots in that part are dropped too, because Gmail delivers to the same inbox with or without them. For every other provider the dots are kept — they can mean different people.

The legal basis for these records is our legitimate interest in preventing fraud and abuse of a free tier. That is the only thing they are for: no advertising, no profile, and no decision about you beyond whether this request gets a key right now.

They are never sold, and not shared with anyone except the services that host this site — the full list is in "Who else touches this" below.

We delete them after 7 days, automatically — a scheduled job, not a promise someone has to remember. Nothing needs them for longer: the limits they enforce look back 24 hours at most.

Why we have it

To email you when early access opens. That is the only reason, and it is the reason you gave it to us.

The legal basis is your consent. You gave it by submitting the form, and you can withdraw it at any time — see "Your choices" below.

We will not sell it, rent it, share it with advertisers, or use it to build an audience on an ad platform.

Where it lives

In a Postgres database hosted by Supabase, in the United States (us-east-1). If you are in the EU or the UK, that means your email is transferred to the US to be stored.

The table it sits in cannot be read from the public internet. The website can only add an address to the list — it cannot list, read, change, or delete anything.

How long we keep it

Until early access opens and you have been invited, or until you ask us to remove it — whichever comes first.

If this product never launches, the list is deleted rather than kept, sold, or transferred.

The abuse records described above — IP addresses and normalised email addresses from key requests — are deleted after 7 days.

The signup-funnel rows and the ad-conversion rows are deleted after 90 days. The conversion rows are also deleted with the key they belong to, whichever comes first.

The refusal records described above are deleted after 90 days. Deleting your key does not delete them: it unlinks them, and what is left says that a call was refused without saying whose it was. We keep them that long because they are how we answer "why did my calls stop working" about something that happened weeks ago.

Your subscription record is kept for as long as your account exists. You can ask us to delete your account; we delete your account and the subscription record with it.

Your choices

Ask us what we hold about you, ask for a copy, ask for a correction, or ask us to delete it. Any of those, by email, and we will do it — no form to fill in and no reason required.

Deletion is deletion: the row is removed, not flagged.

Analytics

We use Vercel Analytics to count page views, and to count visitors — they are two different numbers and we look at both. It sets no cookie, and it never tells us your name, your email address or your IP address.

What it records about one view is the path you opened, the country, the device type, the operating system, the browser, and the host that linked you here. That is the whole list, and it is the whole list because it is what Vercel's own API will break our numbers down by: there is no field in it for an IP address and none for a person. Telling one visitor from another without a cookie happens on Vercel's side, not ours — what reaches us is counts, and there is nothing we can ask it about who anyone was.

We also keep our own record of how the signup flow goes, so we can see where people get stuck. Each step — arriving, asking for a key, copying it, making the first call — is one row: a random identifier for that visit, which step it was, when, the host that linked you here, which product page you landed on, and the campaign tags in the address if you arrived from an ad. Once a key exists, its first 16 characters are attached so the steps join up.

That identifier is kept by your browser for the tab you are in: reloading the page keeps the same one, closing the tab discards it, and a new tab starts a new one. It is not a cookie, not your IP address, and not linked to your name or email. We use it to count how many people finish, and for nothing else.

If you arrived from one of our ads and later got a key or paid, we also keep one row per click with the click identifier, which of those happened, when, and the amount. Those rows are deleted with the key they belong to.

The funnel rows are not deleted with the key, and that is deliberate: "someone arrived and asked for a key" stays true afterwards, and removing it would quietly rewrite our own past conversion rates. What we do remove is the link — the key fragment is erased from those rows the moment the key is deleted, so the step still counts and nothing points back to you.

Both of these are deleted after 90 days regardless — the same window Google uses to match an ad click to what followed.

If you arrive from a Google ad

When you reach this site by clicking one of our Google ads, the address carries a click identifier that Google generated for that click. We store it in a cookie set by this site — not by Google — for 90 days, which is the window Google uses to match a click to what happened after it.

If that visit later turns into a free key or a payment, we tell Google that the click converted. What we send is the click identifier, which of the two happened, when, and the amount if there was one. We do not send your email address, your name, your key, or anything you did on the site.

There is no Google script on this site. Nothing is loaded from Google, no third-party cookie is set, and nothing follows you to other sites. The identifier is uploaded by us, by hand, from our own records.

If you did not arrive from an ad, none of this happens and no advertising cookie is set. You can delete it at any time in your browser; the only consequence is that a conversion we would have reported goes unreported. Signing in sets different cookies, described below.

If you create an account

You can use an API key without an account: the key form asks for an email address and nothing else. An account exists so you can see what a key has left, replace it, and buy credits — none of which we can offer to someone holding only a key, because we cannot tell who is holding it.

Signing in works in one of two ways, and neither uses a password: you type your address and we email you a link that signs you in, or you choose "Continue with Google" and sign in with the Google account for that address. There is no password, so there is no password for us to store or for anyone to steal.

When you sign in, any API key issued to that same email address is attached to your account. That is how a key you got before creating an account shows up there. A key attached this way is marked as unverified — we know the address matches, but not that you are the one holding the key — and buying credits stays off until you replace it.

Your account is your email address and the sign-in time. We never ask you for a name, a company, a phone number or an address, and there is no profile page to fill in. If you sign in with Google, Google also sends us the name and profile picture on that account — it does not offer a way to receive the email alone. We store what Google sends, we do not use it anywhere in the product, and it is deleted with your account, when you ask us to delete it.

When you open your account page, we read your subscription from our own database — we do not call Stripe to load the page, and your email address does not leave our servers for that.

That subscription record holds: the subscription and customer identifiers Stripe gave us, the email address the purchase was made with, the status, when the current period ends, and the price, currency and amount of the plan. It holds nothing about your card — not the number, not the last four digits, not the brand. We never receive those; the payment happens on Stripe.

Signing out deletes the session cookies from your browser. Asking us to delete your account deletes the account and the subscription record with it. Your API key is not deleted with it: it has usage and payments behind it, and turning a key off is a decision a person makes — tell us if you want it off too.

The cookies this site sets

Three kinds, and this is the whole list.

Sign-in session — named sb-skgzksqfilptqoacdkig-auth-token, sometimes split across a numbered pair when it is long. It holds the token that keeps you signed in. It lasts up to 400 days unless you sign out, which deletes it. Only set if you sign in.

Sign-in handshake — the same name with -code-verifier on the end. It exists for the seconds between starting a sign-in and finishing it — by email link or through Google — and proves the sign-in is being finished by the browser that started it. It is discarded as soon as you are signed in.

Ad click — hh_gclid, ninety days, described in the section above. Only set if you arrive from one of our ads.

None of these is an analytics cookie, none is set by a third party, and none follows you to other sites. If you never sign in and never arrive from an ad, this site sets no cookie at all.

The funnel identifier and the campaign tags described under Analytics are not cookies: they live in your browser's tab storage and are discarded when the tab closes.

The record of your past keys

Replacing a key gives you a new secret on the same key — your balance, your allowance and your plan come along. We keep a small history of that: the first 16 characters of each key the row has had, and the dates between which each one was in use.

Those 16 characters are not the key and cannot be turned back into it; they are the same fragment shown to you on your account page. The history has no email address, no IP address and nothing about you — it exists so that usage recorded under an older key still counts as yours.

It is deleted when the key is deleted, in the same operation, because the database is wired that way. There is no separate expiry, and we would rather say that than promise one the database does not keep.

What the product itself archives

Separately from the waitlist, HonestHook records what is trending across public sources — developer platforms such as Hacker News, GitHub, npm and Reddit, and social platforms such as TikTok, Instagram, YouTube and Bluesky.

There are two archives here, and they hold different things.

For each item in the trend archive we store an id, the title or caption, the link, when it was published, a score, a comment count, and its position in that hour's ranking. One source carries a rating as well: for VS Code extensions we keep the star rating, how many ratings it has, and the scale it is out of.

Alongside each of those we record the observation itself: which source it came from, which niche we found it under, the hour it belongs to, and the moment we looked. That is the whole row — no author field, no profile, no follower count, no avatar, no bio, no post body.

We record that same row again every hour, which is what turns a snapshot into a history. A caption written by a person is cut to 200 characters; a title or package description, to 400 — enough to tell one item from another in a list, not enough to reproduce the work.

Two honest exceptions, because they are unavoidable rather than chosen. First: on some platforms the link to a post contains the author's handle — tiktok.com/@handle/video/id is simply what the address of that post is, and removing it would leave a link that goes nowhere. Second: a caption written by a person sometimes mentions another person, and we keep the caption as it was written rather than editing someone's words.

What we removed rather than disclosed: the tracking parameters that came attached to those links. Some carried a device id and a user id belonging to whoever shared the link our supplier happened to capture — a person who never posted anything we archive. Those identified nobody's trend and are now stripped on the way in, and were deleted from the rows already stored.

The profile archive is new, and it is narrower. When a customer asks our API for a public profile, we record one row per hour for that account: the platform, the handle, the hour, the moment we looked, and five numbers — followers, following, post count, whether the account is marked verified, whether it is private. Nothing else. We do not store the display name, the bio, the avatar, the linked website, or the account's internal identifier, even though our API returns some of those to the customer who asked. Returning a field and keeping it are different things, and we only keep the five.

We record a handle only after a customer has asked us for it. We do not crawl for accounts on our own.

Because we record one row per hour, this is a time series: it shows how a public follower count changed over time. We are saying so plainly rather than describing it as a lookup, because that is what it is.

We never log in to a platform, we hold no account on any of them for this purpose, and we do not collect from LinkedIn at all.

Where the trend data comes from

Some sources we read directly from the platform's own public API — Hacker News, GitHub, npm, crates.io, Dev.to, Lemmy, Lobsters, the VS Code marketplace, Bluesky and YouTube.

Part of the historical data in this archive was obtained through a third-party provider of public data. Since September 2026 we collect it ourselves, directly from public content, without logging in.

We are spelling this out because a privacy page that describes an archive without saying where it came from has described half the system — and because the rows collected that way are still in the archive. Correcting how we collect today does not change how yesterday's rows arrived.

This is a real position with a real trade-off, and it is ours rather than something we discovered by accident. If you would rather no scraped source touched your work at all, the removal process below applies to you and we will honour it.

If we archived something you wrote

Write to us and we will remove it. You do not need to prove ownership with a document, quote a statute, involve a lawyer, or explain why — a link to the post and a line saying it is yours is enough.

We answer within seven days. Removal means the rows are deleted from the archive, not hidden behind a flag, and we add the item to a block list so the next hourly run does not simply collect it again.

You can also ask for less than removal: keeping the metrics while dropping the caption and the link is possible, and for most people that is enough. Say which you want and we will do that one.

If your account is private, or you deleted the post after we archived it, tell us and we will remove it without asking anything further. Data collected from a page that has since been closed should not survive in someone else's archive.

Who else touches this

Supabase stores the database, in the United States. Vercel hosts the site and runs the code, and counts page views and visitors without cookies. Resend sends the emails we send you — the welcome message and the key replacement link — and receives your address in order to deliver them. Stripe processes payments if you buy credits — we never see or store your card.

Until September 2026 a third-party provider supplied part of the trend data. It no longer receives anything from us and is no longer part of this list; the rows it supplied remain in the archive, and the section above says so.

Google Ads receives conversion uploads from us when a click on one of our ads turns into a free key or a payment, as described above. And if you choose to sign in with Google, Google learns that you signed in here, and when — that is what choosing that button means. Neither of these runs code on this site: there is no Google script on any page, nothing is loaded from Google, and no third-party cookie is set. If you sign in by email instead, Google is not told that you signed in — the only thing it receives is the conversion upload described above, and only if you arrived from one of our ads.

That is the entire list. There is no data broker, no analytics product that follows you between sites, and nothing here is used to build a profile of you.