Names, gibberish and junk input

Name fields collect the widest variety of real human input and the laziest junk, often from the same form. Parse what is real, flag what is noise, and never let a filter decide that someone's actual name is the problem.

The name field is where verification goes wrong in public. Block a disposable email and nobody notices. Tell a customer their surname is offensive, or greet them as "Dear Garcia" because you split their name in the wrong place, and it ends up in a screenshot. This lesson covers four APIs that each do one narrow job well, and the rules for keeping each in its lane.

All four cost 2 credits a call, so cost is not the constraint here. Judgment is.

Parse names, but keep what the person typed

Most forms ask for "full name" in one box because two boxes annoy people and fail for many cultures. Then the CRM wants first and last for a mail merge. The parser bridges that.

Try it liveHuman Name Parser2 credits
GEThttps://api.apiverve.com/v1/humannameparser
curl "https://api.apiverve.com/v1/humannameparser?name=MR.+MARTINO+PETROS+DE+FLORENCE+%28TINO%29+Jr." \
  -H "x-api-key: YOUR_API_KEY"
Sign in or create a free account to run this with your own key.

Title Mr., first Martino, middle Petros, last de Florence, nick Tino, suffix Jr.

That example shows what the parser is good at: it recognises the title and the suffix, pulls the nickname out of the parentheses, keeps the particle de attached to the surname, and fixes the shouting capitals. It also reads Smith, John Q. correctly as last name Smith, first John, middle Q.. The response adds initials on every plan and a premium formalName such as Mr. de Florence, Martino P. Jr..

Now the cases that should change how you use it.

Dr. Maria del Carmen Lopez-Garcia PhD parses to first Maria, middle del Carmen, last Lopez-garcia. Two things went wrong. del Carmen is part of a compound given name, not a middle name in the English sense, and the second half of the hyphenated surname lost its capital letter. The initials come back MDL, which is not what she would write.

Cher parses to first "" and last Cher. A single name is put in last, so a template that says "Hi {first}" prints "Hi ". Plenty of real people have one name, and plenty more give only one to a form.

asdf qwerty parses cleanly to first Asdf, last Qwerty, initials AQ. The parser structures whatever it is given. It does not judge whether the input is a name.

The rules that follow from those three:

  1. Store the name exactly as typed and use that for anything the person sees, including the greeting on their account page. Parsed parts are for sorting, searching and mail merge.
  2. Never write parsed parts back over the original. The casing fix that helps MARTINO breaks Lopez-Garcia, McDonald and van der Berg.
  3. Fall back when first is empty. Greet with the full name, or ask once: "What should we call you?" That one optional field beats any parser for greeting people correctly.
Check yourself

Your welcome email uses Hi {parsed.first}. A user signs up as Cher. What does the parser return, and what is the fix?

Answer the check above to continue.

Run every example on your own key. Free plan, no card.

Scaling up?

Volume pricing, custom SLAs, and dedicated support for high-traffic teams.

Contact sales