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
  • Premium Fields: Opt into separately-licensed household, spending, vehicle, travel, and interest attributes with include_premium_fields
  • 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, linkedin_profile_pic_url, is_likely_remote_worker, facebook_url, twitter_url, has_bankruptcy_records, has_judgment_records, address_history, education_experience, work_experience, personal_emails, professional_emails, phones, relativesNote: return_fields names top-level keys of the result object, and the requested fields are returned at the top level of that object — the response is flat, with no personal_information / social_media-style grouping. Naming a base field returns 422, since base fields are always included.Example: ["full_name", "personal_emails", "phones"]
boolean
default:"false"
Optional. When true, each matched result gains a nested premium_fields object carrying separately-licensed household, spending, vehicle, travel, and interest attributes. See Premium Fields.Requires the api:premium-fields entitlement on your organization — requesting it without the grant returns 403. Contact your Minerva representative to enable it.Must be a boolean; a string such as "true" is rejected with 422 rather than coerced.Defaults to false, in which case the premium_fields key is omitted from the response entirely.Note: premium_fields is returned in addition to whatever return_fields selects — it is not itself a valid return_fields value, and setting return_fields does not suppress it.

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 - Person Fields

Every person field below is a top-level key of the result object. They are not grouped into personal_information, household_information, financial_information, or social_media objects — those objects do not exist in the response. On a non-match (is_match: false) each is null.
string
Person’s full name
string
First name
string
Middle name
string
Last name
string
Name suffix
string
Gender (“M”, “F”, or null)
string
Date of birth (YYYY-MM-DD format)
integer
Current age
string
Marital status (“M” for married, “S” for single, or null)
string
Household identifier
string
Spouse’s Minerva PID if available
integer
Number of children
boolean
Whether the person is retired
string
Estimated income bracket
string
Estimated wealth bracket
string
Home ownership status (e.g., “Owner”, “Renter”, or null)
boolean
Whether bankruptcy records exist
boolean
Whether judgment records exist
string
LinkedIn profile URL
string
Current title from LinkedIn
string
Industry from LinkedIn
string
LinkedIn profile picture URL
boolean
Whether the person likely works remotely
string
Facebook profile URL
string
Twitter profile URL

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:

Premium Fields

Returned only when the request sets include_premium_fields: true and your organization holds the api:premium-fields entitlement. When the flag is omitted or false, the premium_fields key is absent from every result rather than present-and-null, so existing integrations see a byte-identical response. On a result where is_match is false, premium_fields is null — the same way the core person fields are withheld on a non-match. A matched person with no premium record on file also returns null.
object | null

Premium Fields Request Example

Premium Fields Response Example

Abbreviated — the core enrich fields are returned alongside premium_fields exactly as usual.

Error Responses

  • 400 - Bad Request: Missing required fields or malformed JSON
  • 401 - Unauthorized: Invalid or missing API key
  • 402 - Payment Required: The new records exceed available plan allowance and monthly overage capacity. details includes records_requested, records_available, allowance_records_available, and overage_records_available. Increase the monthly spend limit or upgrade before retrying.
  • 403 - Forbidden: include_premium_fields was requested without the api:premium-fields entitlement. Response code is insufficient_organization_entitlements
  • 413 - Payload Too Large: More than 500 records in request
  • 422 - Unprocessable Entity: Validation errors in record data, invalid match_condition_fields, invalid return_fields, or a non-boolean include_premium_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
  • Every scalar person field is a top-level key of the result object. The response is flat: there are no personal_information, household_information, financial_information, or social_media wrapper objects. The only nested object in a result is premium_fields, and only when explicitly requested
  • When using return_fields, the requested fields are returned at the top level alongside the base fields

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
  • 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: Unchanged. V2 results are flat, exactly as in V1 — every scalar person field and every array field sits at the top level of the result object. V2 adds two keys (relatives, and premium_fields when requested); no existing key moved or was regrouped, so a V1 decoder keeps working against V2.
  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 at the top level, alongside the base fields
  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