Dashboard
Getting Started

Email Verification Status

How Revealed Contact Details Are Returned

Email addresses and mobile numbers are revealed by POST /enrich and POST /bulk, and collected from GET /enrich?id=. Both arrive as arrays of typed values on the row for that profile — this page describes exactly what those arrays contain and, just as importantly, what they do not. 

{
  "linkedinUrl": "linkedin.com/in/qwerty",
  "status": "completed",
  "email": [ { "type": "work", "value": "example@deepenrich.com" } ],
  "mobile": [ { "type": "personal", "value": "+1..." } ]
}

The email and mobile Fields

  • email(object[])
    Each entry carries a type and a value. Present only when enrichFields.email was true and an address was delivered.
  • mobile(object[])
    Each entry carries a type and a value. Present only when enrichFields.mobile was true and a number was delivered.
  • Both are arrays, not strings, and either may be absent. A row that requested both email and mobile may come back with only one of them — so read each key defensively rather than assuming both are present.
No Deliverability Status Is Returned

An entry contains a type and a value and nothing else. There is no per-address status field, no bounce-rate score and no most_probable_email shortcut — the API hands over the addresses and numbers it found, and leaves ranking to you. If you previously branched on a deliverability status, branch on presence instead.

Knowing What Exists Before You Ask

POST /search returns a set of has_* booleans describing which profile fields hold data. They cover education, experience, organisation, title, city, state, country, location, certification, industry and summary.

  • None of them describes email or mobile availability. Search tells you what profile data exists, but says nothing about whether a contact detail can be revealed.

The only way to find out is to call /enrich, which is safe: a profile that yields nothing comes back not_found and is not charged. Attempting a reveal costs you nothing when there is nothing to reveal.

Reading a Row Correctly

Per-row status tells you whether to look for values at all:

  • completed
    At least one requested field was delivered. Read email and mobile, remembering either may be missing.
  • not_found
    Nothing requested could be delivered. The row carries no other keys — no empty arrays to iterate. No credit was charged.

Example — a mixed batch:

"data": [
  { "linkedinUrl": "linkedin.com/in/qwerty",
    "status": "completed",
    "email": [ { "type": "work", "value": "example@deepenrich.com" } ],
    "mobile": [ { "type": "personal", "value": "+1..." } ] },
  { "linkedinUrl": "linkedin.com/in/abcdef",
    "status": "completed",
    "email": [ { "type": "work", "value": "another.example@deepenrich.com" } ] },
  { "linkedinUrl": "linkedin.com/in/lmnopqrs",
    "status": "not_found" }
]

Read row-level status before reading values. The second row requested only an email; the third yielded nothing and is charge-free. A request can be completed while individual rows are not_found — that is the normal outcome for a mixed batch, not a partial failure.

What Each Delivery Costs

  • An email address costs 1 credit, charged when an address is delivered.
  • A mobile number costs 5 credits, charged when a number is delivered.
  • Requesting both for one profile is checked at 6 credits on submission; the deduction reflects only what arrived.

Delivery also draws on separate daily allowances — one counter per address delivered, another per number delivered. See Rate Limit for how those counters work, and Credits & Testing Tips for the full cost table.

 

 

 

 

 

 

On this page