Personal Contact Number API — Result Ordering and Data Sources

The Personal Contact Number Lookup Endpoint returns all phone numbers associated with a person's profile. This guide covers how results are ordered, what types of numbers to expect, and how to use page_size to control cost.

What numbers does it return?

The endpoint aggregates all phone numbers found for a profile — personal mobiles, office lines, and company switchboard numbers alike. The name "Personal Contact" refers to contact info for a person, not exclusively personal or mobile numbers.

Numbers are sourced on a best-effort basis from external data providers, so the response can include false positives such as employer main lines or shared office numbers.

There is no line-type classification in the response (mobile, landline, office). If your workflow requires only mobile numbers, you will need to filter or validate on your end.

How are results ordered?

Results are returned in the order they are stored — there is no ranking by confidence, recency, or source reliability. The first result is not necessarily the most likely personal mobile; it can just as well be an office line or switchboard number.

The ordering is deterministic: repeated calls for the same profile return results in the same order. However, that order is not meaningful for predicting which number is a personal mobile.

Using page_size to control cost

Credits are charged at 1 credit per number returned. Use the page_size parameter to cap how many numbers the API returns per call:

curl \
    -G \
    -H "Authorization: Bearer ${YOUR_API_KEY}" \
    'https://enrichlayer.com/api/v2/contact-api/personal-contact' \
    --data-urlencode 'profile_url=https://www.linkedin.com/in/example' \
    --data-urlencode 'page_size=3'

Because result order does not bias toward personal mobiles, page_size=1 is not a reliable strategy for getting the best mobile number. A small page_size such as 3 gives you a few candidates to filter against, at modest cost.

A call that returns no numbers costs 0 credits.

Dedicated endpoint vs. personal_contact_number=include

The Person Profile endpoint supports a personal_contact_number=include parameter that adds phone numbers to the profile response. This parameter uses only the primary data index — it has no fallback to secondary sources.

The dedicated Personal Contact Number API checks the primary index first and falls back to a secondary source when nothing is found. This is why the dedicated endpoint can return numbers for profiles where personal_contact_number=include returns nothing.

Use the dedicated endpoint when coverage is the priority. Use personal_contact_number=include when you are already calling the Person Profile endpoint and want to avoid an extra request.

Summary

• Numbers are returned in storage order — no confidence or mobile-type ranking
• The endpoint returns all associated phone numbers regardless of line type
• Result order is deterministic but not predictive of personal vs. office numbers
• page_size=1 saves credits but does not guarantee the top result is a mobile
• The dedicated endpoint has broader coverage than personal_contact_number=include due to its secondary source fallback