Genderize.io

Predict the gender most commonly associated with a first or full name using the Genderize.io frequency database. Every lookup returns a probability, so agents can route low-confidence cases to a person.

2 actions API key available

Genderize.io website ↗ Platform Documentation ↗ Capability data verified 2026-07-31

A campaign segment is assembled from an event registration list

Predict Gender For Name Batch returns a label, a probability and a data point count per name

Agent separates the names that clear the probability threshold from those that do not

Agent reads the count behind each confident label, because a high probability over a thin sample is weak evidence

Names with strong probability and a deep sample take the gendered copy variant, everything else takes the neutral one

The campaign owner approves the thin-sample rows before the send goes out

What This Integration Enables

Genderize.io does one thing. Give it a name, get back the gender label most commonly associated with that name, the probability of that label between 0 and 1, and the count of data points the prediction was derived from. Diacritics and non-Latin alphabets are supported, and full names generally predict better than initials. When the name is not in the database, gender comes back null and probability 0.

The narrowness is a feature, and it makes the confidence contract unusually clean. Two numbers come back with every prediction, and both matter. Probability tells you how lopsided the distribution is. Count tells you how much data that distribution rests on. A label at 0.98 over four data points and a label at 0.98 over forty thousand are the same number describing very different evidence, and a flow that only reads probability cannot tell them apart. This is the one connector in FlowRunner's catalog where the second number deserves as much of your logic as the first.

The honest framing of what this is for: addressing people correctly, choosing a grammatical form in a language that inflects, and understanding an audience in aggregate. It is a prediction about a name string, never a fact about a person, and an inferred gender is not a basis for deciding anything consequential about the individual it was inferred from. FlowRunner treats sub-threshold predictions the way it treats any other uncertainty in a flow, as an automation exception that a person resolves rather than a coin the agent flips on its own.

Without FlowRunner

Threshold set once and forgotten A single probability cutoff is hardcoded and nobody revisits what it lets through

Sample depth never examined A 0.98 label built from four data points is treated exactly like one built from forty thousand

Unknown names filled with a default Names the database does not hold get whatever the majority label is, silently

With FlowRunner

Threshold applied per segment The cutoff is a flow parameter the owner can move for a given audience

Sample depth checked alongside probability Confidence and evidence volume both have to clear a bar before copy changes

Unknown names left unknown A null gender stays null and routes to the neutral variant instead of a fabricated one

Use Case Scenarios

Copy variant selection on a registration list

An event drives a few thousand registrations captured as first name, last name and email. Before the follow-up sequence goes out, the agent runs Predict Gender For Name Batch in groups of ten, supplying the event's country so the batch is localised consistently. Names that come back above the threshold with a deep sample route to the copy variant that uses a gendered salutation. Names that come back null, low-probability or thin route to the neutral variant, which reads perfectly well and is what the whole list would have received in the past. The gendered variant is an improvement applied only where the evidence supports it, not a default with exceptions.

Reporting audience composition without labelling people

A team wants the gender balance of a webinar audience for a quarterly report. The agent runs the names through Predict Gender From Name, aggregates immediately to counts, and reports the distribution alongside the share of names that returned null so the reader can see how much of the audience the estimate does not cover. That last figure is the part most reports leave out and the part that determines whether the estimate means anything. Nothing per-person is written back to Klaviyo; only the aggregate reaches the report.

Localised prediction on a multi-country list

The same first name predicts differently by country, so a single global batch produces worse answers than several scoped ones. The agent groups the contact list by the country already on the record, then runs Predict Gender For Name Batch once per country group with that country supplied, since a country applies to every name in a batch. Records with no country on file are held out of the localised runs entirely and handled with the unlocalised default, flagged as such so their lower reliability is visible downstream.

Human-in-Loop Highlight

The gate is the thin-sample slice, and it is specific to how this connector reports itself. Every prediction carries a count, and the rows that make an operator nervous are not the low-probability ones, which the threshold already catches. They are the rows that clear the probability threshold on almost no data: 0.97 confidence built from six data points, which is what an uncommon name looks like when six people happen to share it. Those rows will pass any probability-only rule and land a gendered salutation on a named individual on the strength of six records. So before the send, the agent posts the slice to the campaign owner: "412 names cleared probability 0.90. 37 of them did so on fewer than 50 data points, listed below with their names and counts. Include them in the gendered variant, move them to neutral, or raise the count floor for this segment?" One decision covers the batch, it is recorded, and the threshold the operator picks becomes the parameter for next time.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

2 actions

Gender Prediction

Predict Gender From Name Looks a single first name or full name up in the Genderize.io name database and returns the gender label most commonly associated with that name, the probability of that label between 0 and 1, and the count of data points the prediction was derived from. This is a statistical inference about the name string itself, not a fact about any individual, and gender is null with probability 0 when the name is not in the database. Diacritics and non-Latin alphabets are supported, and full names generally produce better predictions than initials.
Predict Gender For Name Batch Looks up to 10 names up in one request and returns a prediction per name in the same order as the input, each with a gender label, its probability and the count of data points behind it. As with a single lookup, each result describes the name rather than a person, and unknown names come back with a null gender. A country, when supplied, applies to every name in the batch, so group the list by country before batching. Every name counts individually toward the account quota.

Frequently Asked Questions

What can FlowRunner do with Genderize.io?

FlowRunner agents can run Predict Gender From Name and Predict Gender For Name Batch in Genderize.io.

Does connecting Genderize.io to FlowRunner require OAuth?

No. Genderize.io connects to FlowRunner with an API key, no OAuth flow required.

Can Genderize.io trigger a FlowRunner workflow automatically?

Genderize.io doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Genderize.io

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us