Identifiers

Store the personId we return: it’s our stable ID for a person, and the fastest, most reliable way to enrich them again. v3 returns it as a string, and v2 as an integer.

Warning: AggKnowledge IDs are 64-bit, but JavaScript numbers are exact only up to Number.MAX_SAFE_INTEGER (2^53 − 1). v3 returns person, company, HCP and product IDs as JSON strings for that reason; store and compare them as strings. v2 returns personId as a JSON number, which JSON.parse silently rounds above 2^53, corrupting the ID with no error: on v2, parse IDs with a BigInt-aware reviver. Never convert an ID with Number() or parseInt().

Why store the person ID#

Always persist personId after the first successful enrichment. A professional social media URL can change (custom slugs, profile deletions), whereas personId is stable: treat the URL as an acquisition key, not a primary key.

Before you have a person ID#

You can enrich a person by their profile URL instead. Enrichment Inputs covers which URLs we accept and how we resolve them, for customers with a live contract.

If all you hold is a name, a region, an old employer, or a healthcare identifier, Deep Match resolves batches of those fragments to one subject per row and hands back the identifier to store.