API keys that don't store the names you send
Each NameGender API key now has a setting called "Don't store the names this key sends". With it on, the name, email address or username in a request, and the first name we extracted from it, are never written to our request history. The lookup, the result and your credit balance work exactly as before.
You can choose it when you create a key, or switch it on for an existing key from the API keys page in the dashboard. Nothing in your code has to change.
What we record by default
Small API requests are written to a request history so that you can see your recent activity in the dashboard and we can investigate abuse. Each row holds the input, the resolved name, the result, the country, a reference to the API key and the IP address. These rows are deleted after 7 days. Large batches are recorded as job statistics, not one row per name. The privacy policy describes this in full.
For many customers that is fine. For others, the input is a customer's name or email address, and the question in a security review is simply: do you keep it?
What changes with the setting on
| Recorded for each request | Default | Setting on |
|---|---|---|
| Name, email or username you sent | Yes, 7 days | Never written |
| First name we extracted | Yes, 7 days | Never written |
| Result: gender, probability, source | Yes, 7 days | Yes, 7 days |
| Country, API key reference, IP address | Yes, 7 days | Yes, 7 days |
| Credits charged and daily usage totals | Yes | Yes |
The row itself is still written, without the name. Credit accounting, abuse investigation and the daily usage totals depend on it, and none of them need the name. In the dashboard's usage history, those rows show "Not stored" where the input would be.
The setting applies from the moment you turn it on. Rows written before that are deleted when their 7 days run out.
Why we drop names instead of hashing them
Hashing sounds like the safer-looking option, so it is worth saying why we did not use it.
A hash is only irreversible when the set of possible inputs is too large to try. Names are the opposite: our own dataset holds about eight million of them. Anyone who hashes that list once can match a stored hash back to the original name almost instantly, which means a hashed name still points to one name.
Under the GDPR that makes it pseudonymised data, which is still personal data. It would let us say "we don't store names" while storing something that works like a name. So when the setting is on, the column is simply empty.
What the setting does not cover
Being precise about the edges matters more than the headline:
- URLs in web server logs. A
GETrequest carries the name in the URL, and web servers log URLs. Send requests withPOSTand a JSON body, so the name travels in the body instead. Our API documentation shows both. - AI fallback. If you set
ai_fallbackto true and your account has AI lookups enabled, names the dataset cannot answer are sent to a third-party AI provider. It is off by default. Leave it off for data you do not want to leave our servers. - Uploaded files. Spreadsheet jobs are a separate path: the uploaded file is deleted after processing, and the result file is deleted after its retention period.
- Your own systems. Your application logs, proxies and error trackers may record the requests you send. The setting only controls what we keep.
Checking that it works
After you turn the setting on, send one request with that key and open the usage page in the dashboard. The newest row should show "Not stored" in the query column, with the result still visible. The API keys page shows an "Inputs not stored" label under each key that has the setting on.
Frequently asked questions
Does the setting change the result or the price of a lookup? No. The lookup is the same; only what is written to the request history changes.
Can I turn it on for some keys and not others? Yes. It is set per key, so you can keep history on a test key and switch it off for production.
Why not delete everything, including the IP address? The IP address and key reference are how we investigate abuse and answer billing questions, and they are deleted after 7 days like the rest of the row.
Does NameGender store the names I send to the API? By default, for 7 days, so you can see your recent activity. With "Don't store the names this key sends" turned on for a key, the names sent with that key are never written.
Every claim on this page is measurable against your own list. The free tier is enough to check it.
Related
-
Using a name gender API in production: batching, retries and the unknown row
A working checklist for integrating a name gender API: deduplicate, batch by country, retry only what can succeed, store the evidence, and set a threshold.
-
First, middle and last name from any full name, in the same lookup
Every NameGender lookup now splits the input into first_name, middle_name and last_name at no extra cost. The rules, real examples, and where splitting fails.
-
What is a name gender API? How a name becomes male, female or unknown
A name gender API estimates the gender tied to a first name from counted records. What it returns, how each answer is reached, and what it cannot tell you.