PloidDocs
Enrichment

Enrichment

Resolve contact fields for a person from a stable identity.

Contact resolution

POST /v1/enrich

Requires people:enrich. Identify the person with exactly one of linkedin_url, person_id, email (reverse lookup), or name plus company_domain.

curl https://api.ploid.com/v1/enrich \
  -H "Authorization: Bearer $PLOID_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "linkedin_url": "https://www.linkedin.com/in/example",
    "fields": ["work_email", "personal_email", "phone"]
  }'

Every requested field is returned, even when it is not found:

{
  "data": {
    "work_email": {
      "value": "example@company.com",
      "status": "found",
      "confidence": "verified",
      "source": "fullenrich",
      "last_seen": "2026-08-31T00:00:00.000Z"
    },
    "phone": {
      "value": null,
      "status": "not_found",
      "confidence": null,
      "source": null,
      "last_seen": null
    }
  },
  "meta": {
    "usage": {
      "billed": ["work_email"],
      "free": [],
      "not_found": ["phone"]
    }
  }
}

status is unavailable for a provider or transport failure, so it is never silently reported as a clean miss. Only successful reveals are billed.

The legacy enrichments lightweight LinkedIn/contact contract remains supported for existing clients. Deep public evidence lives only at /v1/person, which provides durable runs and 90-day organization-wide rereads.

Partial success

One field can fail without failing the whole person. Unresolved fields return null, and transport or provider failures appear in meta.warnings. Clean not-found fields and failed fields are not charged.

Identity first

Use the strongest known identity anchor available. A canonical LinkedIn URL is safer than a name alone, especially for common names.

Errors and limits

ConditionStatus and code
LinkedIn URL or supported identity is missing422 identity_required or 422 validation_failed

Focused enrichment uses the organization and API-key per-minute buckets; it has no additional route cap. A field-level provider failure normally returns a successful response with that field set to null and a stable entry in meta.warnings. See Errors & rate limits.