Companies and shared mailboxes no longer get a gender: meet name_type

Every NameGender lookup now returns name_type: personal, organization or role. Companies such as "Acme LLC" and shared mailboxes such as "Customer Service" or info@example.com come back with gender: null and no name parts, and the field says why. Only inputs that look like a person are looked up as a name.

The problem it fixes

A name gender API reads the first word of a full name as the first name. For a person that is right. For a company it quietly goes wrong, and the wrong answers look confident.

Until this change, these inputs were looked up by their first word:

The first two are confident answers about a person who does not exist. The last two are unknown, but nothing in the response said why, so an organisation looked the same as an unrecognised person. A lead list with a few hundred company rows ended up with some made-up genders and a pile of unexplained unknowns, and the report built on it counted all of them as people.

Email and username lookups already caught role addresses such as admin@ and placeholder handles such as user123. The name endpoint and spreadsheet uploads did not.

What each value means

personal does not confirm that the input is a real name. A string like "Qzzxvv" is personal with an unknown gender: nothing marks it as a company, and nothing in the data knows it as a name.

What counts as an organisation

• A legal form at the end of an input with at least two words: LLC, Inc., Ltd., Corp., PLC, GmbH, AG, S.A., B.V., AB, Oyj, Pty, Ltd. Şti., A.Ş. and others.
• An organisation word anywhere: University, Foundation, Holding, Group, Clinic, Hospital, Agency, Solutions, Technologies, and the Turkish equivalents such as Üniversitesi, Vakfı and Holding.
• Family business forms: "Smith & Co", "Yılmaz and Sons", "Ali Veli ve Oğulları".

What counts as a role

Inputs made only of role words, such as "Sales Team", "Support", "Guest" or "Customer Service". For email addresses, a role word at the start is enough: info@, noreply@, and also sales.john@, because a shared inbox with a name added is still a shared inbox.

Why the rules are deliberately narrow

Calling a company a person produces a wrong gender. Calling a person a company erases a right one. The second mistake is harder to spot, so the rules lean towards personal when in doubt:

• Words that are also surnames are not treated as company markers. "Bank" and "Church" are real surnames, so "Anna Bank" and "Grace Church" stay personal. Grace Church still gets a gender, which is the right call for a person named Grace Church and the wrong one for a church. We accept that trade-off.
• Short legal forms that double as surnames count only when written like a legal form. "Acme SA" and "Acme S.A." are organisations. "Nguyen Sa" is a person, because Sa is also a Korean and Vietnamese surname. An all-capitals input such as "ACME SA" is left as personal, because capitals no longer tell the two apart.

If your list has a separate company or account-type column, filtering on it will always beat inferring the type from the name.

How to use it

In reports, split rows by name_type before counting genders. An unknown share that includes 200 companies means something different from one that includes 200 unrecognised people.

In CRM enrichment, write name_type next to the gender column. It explains every empty gender on an organisation row without anyone having to open the record.

Before sending a list, remove rows you already know are companies. Each value sent to the API costs one credit, including organisations and roles, because the classification is part of the lookup.

Spreadsheet uploads get a name_type column as well, and the n8n node returns it on every item.

Frequently asked questions

Does name_type cost an extra credit? No. It is part of the same lookup, which costs one credit per value.

Why does my company row say personal? Either it has no marker from the lists above, or its marker is also a surname, or it is written all in capitals with a short legal form such as SA. Those cases are left as personal on purpose, so that people are rarely mistaken for companies.

Can a name gender API tell companies from people? Only by markers in the text, such as legal forms and organisation words. NameGender reports what it found in name_type and never assigns a gender to an input it classifies as an organisation or a role.

Does this change results for real people? Only if a person's full name ends with a legal form or contains an organisation word. Surname-like words were kept out of the lists to keep those cases rare.