NameMatcher: More resilient matching for real-world names
Previously, if an input could not be parsed into a valid name structure, NameMatcher would fail the request. With Version 11.2.0, NameMatcher now applies an additional, resilient matching step for these edge cases. This results in fewer failed requests and more stable behavior when names are incomplete, oddly formatted, or outside expected patterns.
Examples Below are a few real-world style examples that previously would have caused an exception but can now still produce a reliable match result:
-
"John Doe john.doe99@gmail.com" vs "John Doe"
-
"Anita Gonzales" vs "—, Anita Gonzales"
-
"Jorik Diesinger" vs "und Svea Diesinger, Dr. J"
Overall, 11.2.0 improves operational robustness by handling parsing edge cases gracefully while still returning a match only when the outcome is reliable.
More from the team
Beyond "First Name / Last Name": Why One Form Doesn't Fit Every Name
Meet FNU Alice. Except FNU isn't her name. It stands for "First Name Unknown."
Read postAzerbaijani Names: Oğlu, Qızı and a Century of Script Changes
One Azerbaijani name can tell several stories at once: family lineage, gender, linguistic heritage — and even a century of alphabet changes.
Read postCredit Balance API
Documentation for the public website describing the new Credit Balance endpoint.
Read postTalk to the team
Building name matching, parsing or detection into your stack? We're happy to walk you through how it fits.
Schedule a 30-min call