Gender API comparison: fields, accuracy, price and privacy

A gender API comparison is easy to make and easy to make useless. Collecting homepage claims into a table rewards incompatible definitions of accuracy, coverage and database size. A defensible comparison begins with one input fixture and one decision rule.

We operate NameGender, so this page does not award a winner. It gives you a worksheet for comparing us with Genderize, Gender-API.com, GenderAPI.io or another service under the same conditions.

Comparison worksheet

Area	Record	Why it matters
Coverage	Answered rows / submitted rows	Shows how much of your data the service can use
Accuracy when answered	Correct rows / answered rows	Measures quality after unknown results are removed
End-to-end accuracy	Correct rows / submitted rows	Prevents conservative nulls from inflating accuracy
Evidence	Probability, sample count, source	Lets you set and audit a threshold
Localisation	Country input and country used	Names change distribution across markets
Input handling	First, full, email, username, Unicode	Determines how much parsing you must own
Throughput	Batch size, file limits, rate behaviour	Determines implementation and job duration
Billing	Unit, expiry, reset, unknowns, duplicates	Determines real cost rather than list price
Privacy	Retention, deletion, subprocessors, region	Determines whether the workflow fits your obligations
Operations	Versioning, status, errors, support	Determines how safely you can run it in production

Fill this table with links to each vendor's current documentation and the date you checked it. Do not copy a value without its definition.

Build the fixture

Draw a sample from your actual records. Two hundred manually labelled rows is enough to reject a poor fit; a higher-stakes rollout deserves more. Keep the real proportions of countries and writing systems, including the segments you expect to be hard.

Add deliberate edge cases: a genuinely ambiguous name, spelling variants, accented and non-Latin input, empty values, a company name and nonsense. These rows measure whether the API can decline to answer, which is part of accuracy rather than a nuisance to remove.

Send the same first-name value and country hint to each provider. If a vendor accepts a full name or email directly, measure that as a second workflow. Otherwise you would be comparing one service's parser with another service's clean first-name endpoint.

Calculate three quality numbers

Suppose 1,000 rows produce 900 answers, of which 855 are correct:

Coverage is 900 / 1,000 = 90%
Accuracy when answered is 855 / 900 = 95%
End-to-end accuracy is 855 / 1,000 = 85.5%

All three are necessary. Reporting only 95% hides the 100 unresolved rows. Reporting only 90% hides whether the answers were right. End-to-end makes the tradeoff visible but still needs the other two to explain why it moved.

Calculate the same measures per country and script. A large English segment can conceal a near-zero result on a smaller market in the global average.

Inspect the evidence model

Genderize documents probability and count. Gender-API.com documents probability and detailed result metadata, with fields varying by API version. NameGender returns probability, total_names, confidence and source. Other services use their own vocabulary.

Map these into an internal response model without pretending they mean exactly the same thing. An observed ratio derived from counted registrations is different from a model confidence score. A count of supporting records is different from a vendor's total database size.

Test whether an unknown result is explicit. Your internal schema should allow null and preserve the raw provider status. Do not convert unknown to female, male or an empty string.

Test country handling

Use names whose distribution changes across countries and verify that the response changes for a reason you can inspect. Country should narrow the relevant evidence pool; it should not be a decorative echo of the request.

Record where the country comes from in your system. A declared market or address field may be appropriate. Request IP and interface locale often are not. A precise answer to the wrong population is still wrong.

Compare throughput with one real job

Run the same 10,000-row file or chunked API job through each candidate in a non-production environment. Measure elapsed time, retries, rate responses, unknown handling, output ordering and the effort required to resume after interruption.

Batch limits affect architecture. Genderize's official reference currently documents up to 100 names in one request; NameGender's current bulk limit is also exposed in its documentation and may be configured over time. Read limits at integration time rather than hard-coding an assumption from a comparison article.

For a spreadsheet task, include upload, column mapping and download in the measurement. The fastest endpoint can still create the slowest human workflow if every error requires manual reconstruction.

Calculate total price

Model at least three months: a normal month, a peak and an idle month. Record whether units expire or reset, whether unknown results and duplicate names consume units, and what happens after the limit.

GenderAPI.io's pricing page, for example, distinguishes monthly subscriptions that reset from one-time credits that do not expire. Genderize's FAQ says usage is counted by name, including names inside a batch. NameGender sells purchased credits that remain until used and deduplicates repeated lookup keys in managed batch files.

Translate each model into the annual cost of your pattern. A monthly plan often fits continuous usage; a one-time balance often fits periodic cleanup. Neither is universally cheaper.

Review privacy before sending the fixture

Names can be personal data when linked to identifiable records. Send only the fields required for the lookup, use synthetic or appropriately authorised data during vendor evaluation, and read the current privacy notice and data-processing terms.

Ask about request logging, retention, deletion, subprocessors, training use, processing region and incident notification. For file workflows, ask how long source and result files remain available. Document the answers with dates because policies change independently of API code.

Finally, decide whether name-based inference is appropriate at all. It can support aggregate analysis or optional low-risk personalisation with a neutral fallback. It should not determine employment, medical, financial, insurance, legal or eligibility outcomes.

Make the decision reproducible

Keep the fixture, adapter code, raw responses, calculation script, pricing assumptions and decision threshold together. Record the test date and API versions. Repeat the run before a large renewal or after a material data-version change.

The result may not be one provider for every task. A spreadsheet team can choose a managed file workflow while a product team keeps a simpler endpoint. The goal is not one universal winner; it is an auditable reason for each production choice.