Skip to main content
This page collects identifier recipes for Person Enrich. Each example is a full working request you can copy, paste, and adapt. For the core walkthrough (first enrichment by profile URL, response shape), see Person Enrich. For the request/response schema and errors, see Enrich reference.
Replace YOUR_API_KEY in each example with your actual API key. All requests require the x-api-version: 2025-11-01 header.

​
Reverse lookup: find a person from a business email

You do not always have a profile URL. If you have a business email, use business_emails to reverse-lookup the person behind the address. 
curl --request POST \
  --url https://api.crustdata.com/person/enrich \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "business_emails": ["abhilash@crustdata.com"],
    "min_similarity_score": 0.8
  }'
Response trimmed for clarity.

​
How email reverse lookup works

When you submit a business email, the API resolves it to a public person profile. The response structure is identical to a profile URL lookup, but match_type is business_email and matched_on shows the email you submitted. The min_similarity_score parameter controls how strict the matching is. A value of 0.8 means the API only returns matches where it is at least 80% confident the email belongs to the person. Higher values give fewer but more reliable results.
min_similarity_scoreWhen to use
0.9 – 1.0High-confidence workflows (CRM enrichment, automated pipelines)
0.7 – 0.8Balanced accuracy for most use cases
0.5 – 0.6Exploratory lookups where you will manually verify
Not setReturns all matches regardless of confidence

​
Handle no-match results

Not every identifier will resolve to a person. When there is no match, the matches array is empty. 
curl --request POST \
  --url https://api.crustdata.com/person/enrich \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "business_emails": ["nonexistent@unknowndomain.com"],
    "min_similarity_score": 0.8
  }'
You still get a response entry for the identifier — matched_on tells you which input had no match. This makes it easy to track which lookups succeeded and which need a different approach.

​
Batch enrichment: look up multiple people at once

You can enrich up to 25 identifiers in a single request. The response returns one entry per identifier, in the same order you submitted them. 
curl --request POST \
  --url https://api.crustdata.com/person/enrich \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "professional_network_profile_urls": [
      "https://www.linkedin.com/in/dvdhsu/",
      "https://www.linkedin.com/in/abhilashchowdhary/"
    ]
  }'
Response trimmed for clarity.

​
Batch enrichment tips

  • The maximum batch size is 25 identifiers per request.
  • You must use one identifier type per request — either all profile URLs or all emails, not a mix.
  • Each entry in the response corresponds to the input at the same position, so you can match results back to your input list by index.
  • If some identifiers fail to match, their matches array will be empty, but the request still succeeds for the others.

​
Choosing between profile URL and email enrichment

Both paths return the same person_data shape, but they work differently.
Profile URLBusiness email
Identifierprofessional_network_profile_urlsbusiness_emails
Match typeDirect lookup — the URL uniquely identifies a profileReverse lookup — the API infers which profile owns the email
ConfidenceAlways 1.0 (exact match)Varies. Use min_similarity_score to control the threshold
Best forWhen you already have the profile URLWhen you only have an email
Batch limitUp to 25 URLs per requestUp to 25 emails per request

​
Common workflow: Search then Enrich

The most powerful pattern combines Person Search with Person Enrich. Search finds people matching your criteria; Enrich gets the full profile for each match. Step 1: Search for decision-makers at a target company. 
curl --request POST \
  --url https://api.crustdata.com/person/search \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "filters": {
      "op": "and",
      "conditions": [
        {
          "field": "experience.employment_details.current.company_name",
          "type": "in",
          "value": ["Retool"]
        },
        {
          "field": "experience.employment_details.current.title",
          "type": "(.)",
          "value": "VP|Director|Head of"
        }
      ]
    },
    "limit": 5
  }'
Step 2: Take the profile URLs from the search results and enrich them for full profiles. 
curl --request POST \
  --url https://api.crustdata.com/person/enrich \
  --header 'authorization: Bearer YOUR_API_KEY' \
  --header 'content-type: application/json' \
  --header 'x-api-version: 2025-11-01' \
  --data '{
    "professional_network_profile_urls": [
      "https://www.linkedin.com/in/dvdhsu/",
      "https://www.linkedin.com/in/abhilashchowdhary/"
    ]
  }'
This two-step pattern is the foundation for most sales, recruiting, and research workflows. Search narrows the universe; Enrich fills in the details.

​
Next steps

  • Reference — request parameters, valid fields values, person_data sections, and errors.
  • Enrich reference — request parameters, response fields, advanced flags, errors.
  • Person Live Enrich — fetch fresh profile data from the web when cached enrich is not enough.