# How to choose a gender API Plain-Markdown twin of . Last reviewed 2026-09-01. Prices and the country count are rendered live on the HTML page. Every provider in this category will tell you it is accurate, and none of them measured it on your list. Here is what actually separates them — and our own answer under each, so you can hold us to the same questions. **No competitor is named on this page.** Not out of politeness: a page built on someone else's pricing and feature list is wrong the moment they change either. ## The short answer - Compare on **what one result hands you**. A bare label cannot be thresholded; a probability plus a sample count can. That decides whether you automate part of the file or all of it by hand. - **Ignore headline accuracy percentages, including ours** — we do not publish one, because we have not measured it on a published benchmark. Measure it yourself on a few hundred of your own rows. - A bigger name database is not automatically better: a name counts the same whether three records back it or fifty thousand. - Then check the four things people forget — localization by country, stability of the answer over years, what comes back for an unknown name, and where the data is processed. ## Start with what a single result gives you This is the criterion that changes how much work you have to do, and it is visible in a provider's example response before you sign anything. | Response shape | What you can do with it | |---|---| | `gender` only | Filter on the label. **No cut-off is possible** — trust every row, or check every row | | `gender` + `probability` | Set a confidence cut-off. But 0.98 from three records and 0.98 from three thousand look identical | | `gender` + `probability` + `samples` | Set a cut-off **and** know whether it rests on enough evidence to believe | A gender label on its own is a verdict with no working shown. You can either apply it everywhere or check it everywhere; there is no middle. **Our answer:** every result carries a probability and a sample count, and the CSV/Excel output writes them into your file as columns (`ga_gender`, `ga_accuracy`, `ga_samples`), so the same threshold works whether you are calling the API or opening a spreadsheet. Note the two scales, because mixing them up is easy: the API's `probability` is 0–1, while the spreadsheet's `ga_accuracy` column is 0–100. ## Why a coverage number does not settle it Both of these count as "covered" by any database that holds them: | In the database | Records behind it | What you can do with the row | |---|---|---| | a widely held name | tens of thousands | act on it automatically | | a rare name | three | hold it back, or greet neutrally | A headline "names in the database" figure counts them identically. Only the number beside each result tells them apart. We hold 9,124,598 names across 192 countries, and we put those figures on the homepage like everyone else does. They are worth exactly this much: they tell you how often you will get an answer at all, and nothing about whether a particular answer is worth using. Do not choose on them — ours or anyone's. The test that does settle it costs an afternoon: take a few hundred rows from your own data where you already know the right answer, include the ones you expect to be hard, and run them through every provider on your shortlist. The names everybody gets right tell you nothing. ## The checklist Nine questions, in the order they tend to matter. Ask the same of anyone else you are looking at, and ask for the answers in writing rather than from a feature grid. | Ask | Why it matters | Our answer | |---|---|---| | What does one result contain? | Decides whether you can automate the confident rows | Gender, a probability, and the number of records behind it | | Can the same name answer differently by country? | `Andrea` is male in Italy and female in Germany; one global answer is wrong in one of them | Yes — by country code, browser locale or IP | | Will the same request answer the same way next year? | An audit asks how a record was classified | Yes — arithmetic over stored records, not a generated guess | | What comes back for a name it does not know? | An empty field can be filtered; a plausible guess cannot be spotted | An explicit not-found and a sample count that says why — never an invented answer | | Is there a route that needs no developer? | The person with the list is usually not the person who can call an API | CSV and Excel upload, original workbook preserved | | Where is the data processed, and is there a DPA? | A list of customer names is personal data | German company, servers in Germany, processing in the EU, DPA on request | | Does unused capacity expire? | A one-off clean-up should not need a subscription that outlives it | Prepaid credits, and they do not expire | | Can I test it before talking to anyone? | If evaluating needs a sales call, you cannot compare shortlists in an afternoon | 100 free lookups a month, no card, no call | | What is the published accuracy? | A single percentage describes the name set it was measured on, which is not yours | **We do not publish one** — see below | ## The accuracy figure we will not give you You will be quoted percentages in this market. We have no measured one to quote: there is no published benchmark of ours on a labelled name set, so any figure we printed would be a marketing number wearing a lab coat. It is also less useful than it sounds. Accuracy on a name-gender lookup depends almost entirely on which names you ask about — a list of common German first names and a list of transliterated surnames from a dozen scripts will not produce the same number from any provider alive. A single percentage tells you about the set it was measured on, and your list is not that set. When you are quoted one, the questions that make it meaningful are: **measured on which names, how many, labelled by whom, and counting "unknown" as what?** If those answers are not available, the percentage is decoration. ## How to run the evaluation in an afternoon This page keeps telling you to measure it on your own data, so here is the method. It works the same for every provider on your shortlist, and step 5 is the one that decides the project. 1. **Pull 200–300 rows you already know the answer for.** From your real data, not a list of famous names. Deliberately include the awkward ones: rare names, non-Western names, surname-first entries, single-word names, hyphenated and married names. 2. **Do not clean them up first.** The trailing whitespace, the titles, the `Dr.` and the ALL CAPS are part of what you are testing. A provider that only works on tidy input has not solved your problem. 3. **Keep the whole response, not just the label.** You need the probability and the sample count in step 5 — and if a provider does not return them, that is itself the result of the test. 4. **Score three outcomes separately — right, wrong, and no answer.** This is where most evaluations go wrong: collapsing "wrong" and "unknown" into one number hides the difference that matters. An unknown you can filter costs you a neutral greeting. A confident wrong answer costs you the customer. 5. **Now apply a threshold and score it again.** Accept only rows above your cut-off — say `probability >= 0.9` with `samples >= 50` — and measure two things: what share of the file that covers, and the error rate *within* it. That pair is the real answer, because it tells you how much of the work disappears and how much risk comes with it. 6. **While you are in there, check the operational things.** How long 300 rows take. What an error response looks like when you send rubbish. Whether the identical request twice returns the identical answer. Whether the trial needed a phone call. Step 5 is why the response shape matters more than any headline figure: without a probability and a sample count there is no threshold to apply, so the honest answer to "how much of this file can I automate?" becomes "all of it or none of it". 100 free lookups a month covers a 300-row test three times over. ## If you are also weighing up a language model Increasingly the shortlist is not two APIs but an API and a prompt. That comparison turns on different things — cost per million rows, whether the same input gives the same output twice, and what you can show an auditor — so it has its own page: ## What integrating actually looks like One credit per lookup, 100 names per batch request, no ceiling on the number of requests. - Official clients for PHP, Python, Node, Java, Go, Ruby, Rust, Perl and .NET: - Full v2 reference with an OpenAPI description, and RFC 7807 problem responses so errors are machine-readable: - A native Excel add-in, a Shopify app, ready-made integrations for Google Sheets, HubSpot, Salesforce and Zapier, and a hosted MCP server for AI tooling: - One-off file: ## FAQ **What should I compare gender APIs on?** On what a single result hands you, not on a headline accuracy figure. Then: whether the same name can resolve differently by country, whether the answer is stable over time, what happens when the name is unknown, and where the data is processed. **How do I test one properly?** On your own list, not on a sample of famous names. A few hundred rows you already know the answer for, including the awkward ones. 100 free lookups a month is enough for that. **Is a bigger name database better?** Not on its own. Size matters for how often you get any answer; the sample count matters for whether you should use it. **What accuracy do you publish?** No measured figure, deliberately. What we give you instead is the evidence per answer, so you can measure accuracy on your own data. **Does it matter where the data is processed?** It does if your list is customer names. German company, servers in Germany, processing in the EU, DPA on request: **What are the questions people forget to ask?** What happens to an unknown name; whether the same request answers the same way next year; and whether unused capacity expires. ## Start 100 free lookups a month, no credit card and no call: