Salutations in Clay: Herr/Frau, Madame, Mr/Ms in one column

One HTTP API column in Clay can turn a full-name column into a greeting your email template can use as it is: "Sehr geehrte Frau Müller," for a German prospect, "Madame," for a French one, "Geachte heer De Vries," for a Dutch one. The same response carries the gender, its probability and the name split into first and last name, so you do not need a formula column to build the greeting or a second step to split names.

Clay's built-in Predict Gender enrichment returns a gender label. That is enough for an English "Hi Anna", but German, French and Dutch outbound needs the courtesy title and the surname in the right form, and the label alone leaves that work to you. This guide sets up the column once; it then runs on every new row.

What you need

• A Clay table with a full-name column (or first and last name), and ideally a country column.
• A NameGender API key. A free account includes 100 lookups a day, enough to test the column on a sample.

1. Save the key as a header account

In the table, click Add enrichment, search for HTTP API, and switch from Generate to Configure.

Open Select header account, choose + Add account, and under API Request Headers add one pair:

Name it "NameGender" and save. Every HTTP API column in the workspace can now use the key without showing it in plain text to people who can see the table.

2. Configure the request

Type / in a value field to pick the column. If you have separate name columns, send first_name and last_name instead of name.

The country decides the language of the greeting and settles names that change sex across borders. Without it, the language falls back to English. If you have no country column but do have the prospect's language, send language=de (or fr, nl, es, it, pt, pl, tr, ja, en).

Turn on Remove empty fields from request, so rows without a country are sent without the parameter rather than with an empty one.

3. Test on one row

Click Test. For "Müller, Anna" with country DE, the response is:

{
  "language": "de",
  "form": "gendered",
  "salutation": {
    "formal": "Sehr geehrte Frau Müller,",
    "informal": "Liebe Anna,",
    "neutral": "Guten Tag Anna Müller,"
  },
  "gender": "female",
  "probability": 95,
  "first_name": "Anna",
  "last_name": "Müller",
  "name_type": "personal",
  "country": "DE"
}

Note that "Müller, Anna" was written surname first; the split still puts Anna in first_name.

4. Pull the fields you will use into columns

From the column's result, add these as their own columns:

Then reference the Salutation column in your sequence tool's template instead of a hard-coded "Dear".

What it returns for real names

These are live responses from the endpoint:

The Andrea Rossi rows are worth a second look. Andrea is mostly a man's name in Italy and mostly a woman's in the US, so the greeting follows the country; without the country column every row would get the same answer. In France the name is split closely enough (79% male) that the API does not guess and returns the greeting that fits anyone. And "Sales Team" is recognised as a role rather than a person, so it gets the impersonal German opening instead of a guessed "Herr".

When the gender is unsure

When the gender's probability is below 90%, or the name is unknown, form comes back as neutral and salutation.formal holds a greeting that works for anyone: "Guten Tag Kim Lee," in German, "Madame, Monsieur," in French, "Dear Kim Lee:" in American English. reason says why (below_min_probability). You do not have to filter those rows yourself: the formal salutation is always safe to send.

To move the cut-off, add min_probability as a query parameter, anywhere from 50 to 100. A higher value sends more rows to the neutral form; a lower one gives gendered greetings to more of them. For how often a sex-of-name greeting is wrong in each country, and what a 90% threshold fixes, see salutation errors by country.

Cost and limits

Each row costs one credit. The column respects the rate you set under Request limit and Duration (ms); 20 requests per 1000 ms is well inside the API's limit of 1,200 requests a minute per key. To process a large existing list in one go rather than row by row, upload it as a file and import the result back into Clay.

If you would rather not have names stored with request logs, switch off input storage on the key you use for Clay; see API keys that do not store names.