Enrich v2
Enrich
Enrich v2
Enhanced enrichment with direct lookups, flexible matching, and selective field returns
POST
Enrich v2
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_pidorlinkedin_urlfor instant results without fuzzy matching - Match Conditions: Control which fields must be present for a match to be returned
- Selective Returns: Use
return_fieldsto get only the data you need and optimize response size - New Data: Includes
relativesfield 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 JSON401- Unauthorized: Invalid or missing API key402- Payment Required: Minerva credits exhausted. Response body includesrecords_remaining(estimated records remaining based on your credit balance) andrecords_requested(batch size that was rejected)413- Payload Too Large: More than 500 records in request422- Unprocessable Entity: Validation errors in record data, invalidmatch_condition_fields, or invalidreturn_fields429- Too Many Requests: Rate limit exceeded500- Internal Server Error: Unexpected server error
Notes
Performance Optimization
- Use
return_fieldsto 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/resolvedue 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
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.
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_fieldsfilters 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
relativesfield is included in full responses but is not available as an explicitreturn_fieldsoption - Related fields are grouped into nested objects:
personal_information,household_information,financial_information, andsocial_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 havevalidation_errors populated and may
have is_match: false.
New Features in V2
- Direct Lookups:
minerva_pidandlinkedin_urlas input fields for instant enrichment - Structured Response: Fields are organized into logical nested objects (
personal_information,household_information,financial_information,social_media) relativesfield provides family relationship data with linked Minerva PIDsreturn_fieldsallows 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:- URL Change:
/v1/enrich→/v2/enrich - Response Structure Change: Fields are now organized into nested objects:
personal_information: Contains name, gender, DOB, age, marital statushousehold_information: Contains household ID, spouse PID, number of childrenfinancial_information: Contains income/wealth estimates, home ownership, bankruptcy/judgment recordssocial_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
- New Direct Lookup Options:
- Add
minerva_pidto your input records if you have previously resolved persons - Add
linkedin_urlif you have LinkedIn profiles - These provide instant enrichment without fuzzy matching
- Add
- Performance Optimization: Use
return_fieldsto 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
- Data Quality Control: Use
match_condition_fieldsto ensure matches have required data - New Data:
relativesfield now provides family relationship information - Flexible Input: Name is no longer required when using direct PID or LinkedIn lookups
- Same Record Limit: Maximum 500 records per request (unchanged from V1)
Key Differences from /v2/resolve
/v2/enrichacceptsminerva_pidandlinkedin_urlas INPUT fields for direct lookups/v2/resolvedoes NOT accept these fields as inputs (uses reverse lookup instead via single email/phone)/v2/enrichrequiresrecord_idto be provided/v2/resolvehas optionalrecord_id/v2/enrichreturns comprehensive enrichment data/v2/resolveonly returns match information and LinkedIn URL