Skip to main content
POST
Enrich v2

Quick Answer

How do I enrich a user/person/contact? Use this endpoint to get detailed information about a person including their work history, contact details, demographics, addresses, and more.Common questions this endpoint answers:
  • How do I enrich a user?
  • How do I get comprehensive data about a person?
  • How do I find someone’s email and phone number?
  • How do I look up a person’s job history and education?
  • How do I get demographic and financial information about someone?
  • How can I enrich my customer database with additional fields?
  • How do I append data to my contact records?
What you need: Follow the Enrich input rules for accepted identifiers and record shapes.What you get back: Comprehensive profile with work experience, education, contact info (emails, phones), addresses, demographics, family relationships, financial estimates, and social profiles.

Overview

The V2 Enrich endpoint combines identity resolution and comprehensive data enrichment with enhanced controls and performance. See Enrich Input Rules for accepted identifiers, record shapes, and contact-field requirements.

Key Enhancements in V2

  • Direct Lookups: Enrich by minerva_pid or linkedin_url for instant results without fuzzy matching
  • Match Conditions: Control which fields must be present for a match to be returned
  • Selective Returns: Use return_fields to get only the data you need and optimize response size
  • New Data: Includes relatives field with family relationship information
  • Improved Performance: Optimized data retrieval with parallel processing and support for mixed lookup modes

Request

Headers

string
required
Your API key for authentication
string
required
application/json

Request Body

object[]
required
An array of person records to enrich. Maximum 500 records per request. Each record must follow one of the supported Enrich input rules.
string[]
Optional list of fields that must be present in the enriched data for a record to be returned as a match. Maximum 3 fields.Valid options: linkedin_url, gender, estimated_income_range, estimated_wealth_range, email, personal_email, professional_email, phone, mobile_phone, home_ownership_statusExample: ["email"] or ["phone", "linkedin_url"]
string[]
Optional list of additional fields to return beyond the base fields. Use this to control response size and reduce latency. If not specified, all available fields are returned.Base fields (always returned): record_id, is_match, minerva_pid, match_score, validation_errorsAvailable fields: full_name, first_name, middle_name, last_name, name_suffix, gender, dob, age, marital_status, minerva_household_id, minerva_spouse_pid, number_of_children, is_retired, estimated_income_range, estimated_wealth_range, home_ownership_status, linkedin_url, linkedin_title, linkedin_industry, is_likely_remote_worker, facebook_url, twitter_url, has_bankruptcy_records, has_judgment_records, address_history, education_experience, work_experience, personal_emails, professional_emails, phonesNote: When using return_fields, only the requested fields are included, but they are returned within their respective nested objects (personal_information, household_information, financial_information, social_media). The relatives field is automatically included when returning all fields, but cannot be explicitly requested via return_fields.Example: ["full_name", "personal_emails", "phones"]

Request Examples

Standard Fuzzy Matching with Selective Returns

Direct Minerva PID Lookup

Direct LinkedIn URL Lookup

Fuzzy Matching with a Full Address

Fuzzy Matching with a Parsed Address

Mixed Lookup Types in One Request

Response

Response Structure

string
Unique identifier for this API request
array
Array of enrichment results
string
ISO 8601 timestamp when the request was completed

Result Object - Base Fields (Always Returned)

string
Your identifier from the request
boolean
Whether a match was found
string
Minerva person identifier
number
Confidence score for the match, as an additive point total — not a 0-1 or 0-100 scale. Fuzzy matches routinely score above 100, direct lookups return fixed values, and the field can be null even on a successful match. See Interpreting match_score.
object
Any validation errors from the input

Result Object - Personal Information

object
Object containing personal demographic details

Result Object - Household Information

object
Object containing household and family details

Result Object - Financial Information

object
Object containing financial and legal record details

Result Object - Social Media

object
Object containing social media profiles and professional information

Result Object - Contact Information

array
Array of personal email addresses with ranking
array
Array of professional email addresses with ranking
array
Array of phone numbers with type and ranking
Email Object
integer
Rank/priority of this email (1 = highest priority)
string
Email address
Phone Object
integer
Rank/priority of this phone (1 = highest priority)
string
Phone type (e.g., “Mobile”, “Landline”)
string
Phone number

Result Object - Family Relationships (New in V2)

array
New in V2: Array of family relationships
Relative Object
string
Minerva PID of the relative
string
Relative’s first name
string
Relative’s last name
string
Type of relationship (e.g., “Parent”, “Child”, “Sibling”)
string
Additional relationship details

Result Object - Address History

array
Array of address records with property details
Address Object
integer
Rank of address (1 = most recent/current)
string
Unique address identifier
string
Street address
string
Apartment/unit number
string
City
string
State
string
ZIP code
string
ZIP+4 extension
string
Ownership status (“Owned” / “Rented”)
boolean
Whether person currently owns this property (TRUE / FALSE)
string
Date property was purchased
number
Purchase price in USD
number
Current estimated value in USD
number
Estimated monthly rental value in USD
number
Annual property tax in USD
number
Outstanding mortgage balance in USD
number
Estimated equity in USD
number
Square footage
number
Number of bedrooms
number
Number of bathrooms
string
First date person was associated with this address
string
Last date person was associated with this address

Result Object - Work Experience

array
Array of work history records
Work Experience Object
integer
Rank (1 = most recent)
string
Unique experience identifier
string
Company name
string
Company LinkedIn URL
string
Company website
string
Company industry
string
NAICS industry classification code
string
NAICS industry description
string
SIC industry code
string
SIC industry description
string
Job title
string
Standardized job title
string
Seniority level (e.g., “Senior”, “Manager”, “Executive”)
string
Department
string
Employment type (e.g., “Full-time”, “Part-time”)
string
Employment status (e.g., “Current”, “Past”)
string
Start date
string
End date (null if current)
string
Work location city
string
Work location state
string
Work location country

Result Object - Education

array
Array of education records
Education Object
integer
Rank (1 = most recent)
string
Unique experience identifier
string
School/university name
string
Institution LinkedIn URL
string
Additional education details
string
Degree level (e.g., “Bachelor’s”, “Master’s”, “PhD”)
array
Array of major fields of study
array
Array of minor fields of study
string
Start date
string
Graduation date
Error responses include statusCode and body fields for backward compatibility with existing integrations. These are deprecated — prefer the HTTP status code and the top-level code / message / api_request_id fields directly. (The deprecated nested body still carries the legacy error_message.)

Alternative Response Example (With return_fields)

When using return_fields: ["full_name", "linkedin_url", "personal_emails"], only the requested fields are returned alongside the base fields:

Error Responses

  • 400 - Bad Request: Missing required fields or malformed JSON
  • 401 - Unauthorized: Invalid or missing API key
  • 402 - Payment Required: Minerva credits exhausted. Response body includes records_remaining (estimated records remaining based on your credit balance) and records_requested (batch size that was rejected)
  • 413 - Payload Too Large: More than 500 records in request
  • 422 - Unprocessable Entity: Validation errors in record data, invalid match_condition_fields, or invalid return_fields
  • 429 - Too Many Requests: Rate limit exceeded
  • 500 - Internal Server Error: Unexpected server error

Notes

Performance Optimization

  • Use return_fields to request only needed data - significantly reduces response size and improves latency
  • Direct PID lookups (minerva_pid) are fastest - use when you have previously resolved a person
  • LinkedIn URL lookups provide quick resolution when you have LinkedIn profiles
  • Fuzzy matching is comprehensive but slower - use when you need identity resolution
  • Maximum 500 records per request (lower than /v2/resolve due to enriched data volume)
  • Mix lookup modes in a single request for optimal performance

Interpreting match_score

match_score is an additive point total, not a normalized 0-1 or 0-100 confidence. For a fuzzy match it is the sum of two components:
  • Name — up to 60 points, based on how closely the input name matches the person’s known names and aliases
  • Contact info — points for matching email, phone, and address evidence, weighted by how strongly each value is associated with the person
Because the contact-info component grows with each additional match, there is no upper bound: a record matched on a name plus several emails and phones commonly scores 110-130. Every fuzzy match returned with is_match: true has already cleared Minerva’s internal threshold and scores at least 50.
Compare scores against each other, not against a fixed ceiling. Thresholding on a percentage (for example, “accept above 0.8” or “above 80%”) will not behave the way you expect.
Direct lookups don’t run the scoring algorithm, so V2 reports them differently depending on which lookup modes corroborate each other: A null score is therefore not a weak match — for a direct minerva_pid lookup it means you addressed the person by identifier, so there was nothing to score. Treat is_match as the source of truth for whether a record matched, and don’t require match_score to be present. Scores are rounded to two decimal places. If you need stricter results, prefer match_condition_fields over a score threshold: it filters on which data is actually populated, which is both verifiable and stable across lookup modes.

Match Condition Fields

  • match_condition_fields filters results to only return matches that have the specified fields populated
  • Helps maintain data quality requirements by ensuring minimum data availability
  • Maximum 3 fields can be specified
  • Available condition fields: linkedin_url, gender, estimated_income_range, estimated_wealth_range, email, personal_email, professional_email, phone, mobile_phone, home_ownership_status
  • Example: ["email", "linkedin_url"] will only return matches that have both an email and LinkedIn profile

Data Availability

  • All list fields (emails, phones, addresses, work, education, relatives) return empty arrays [] if no data is available
  • Dates are returned in ISO 8601 format (YYYY-MM-DD)
  • Financial figures are in USD
  • Arrays are ordered by rank, with rank=1 being the most recent/relevant
  • The relatives field is included in full responses but is not available as an explicit return_fields option
  • Related fields are grouped into nested objects: personal_information, household_information, financial_information, and social_media
  • When using return_fields, only requested fields are included within their respective nested objects

Validation

Input validation follows the Enrich input rules. Records with validation errors will have validation_errors populated and may have is_match: false.

New Features in V2

  • Direct Lookups: minerva_pid and linkedin_url as input fields for instant enrichment
  • Structured Response: Fields are organized into logical nested objects (personal_information, household_information, financial_information, social_media)
  • relatives field provides family relationship data with linked Minerva PIDs
  • return_fields allows precise control over response payload for cost optimization
  • Flexible input requirements: Name is optional when using direct lookups

Migration from V1

If you’re upgrading from V1:
  1. URL Change: /v1/enrich/v2/enrich
  2. Response Structure Change: Fields are now organized into nested objects:
    • personal_information: Contains name, gender, DOB, age, marital status
    • household_information: Contains household ID, spouse PID, number of children
    • financial_information: Contains income/wealth estimates, home ownership, bankruptcy/judgment records
    • social_media: Contains LinkedIn, Facebook, Twitter URLs and professional details
    • Array fields (address_history, work_experience, education_experience, personal_emails, professional_emails, phones, relatives) remain at the top level
  3. New Direct Lookup Options:
    • Add minerva_pid to your input records if you have previously resolved persons
    • Add linkedin_url if you have LinkedIn profiles
    • These provide instant enrichment without fuzzy matching
  4. Performance Optimization: Use return_fields to request only needed data
    • Reduces response payload size significantly
    • Lowers latency and data transfer costs
    • Base fields always returned: record_id, is_match, minerva_pid, match_score, validation_errors
    • Requested fields are returned within their respective nested objects
  5. Data Quality Control: Use match_condition_fields to ensure matches have required data
  6. New Data: relatives field now provides family relationship information
  7. Flexible Input: Name is no longer required when using direct PID or LinkedIn lookups
  8. Same Record Limit: Maximum 500 records per request (unchanged from V1)

Key Differences from /v2/resolve

  • /v2/enrich accepts minerva_pid and linkedin_url as INPUT fields for direct lookups
  • /v2/resolve does NOT accept these fields as inputs (uses reverse lookup instead via single email/phone)
  • /v2/enrich requires record_id to be provided
  • /v2/resolve has optional record_id
  • /v2/enrich returns comprehensive enrichment data
  • /v2/resolve only returns match information and LinkedIn URL