All integrations

People Data Labs

DATA · DATA & ANALYTICS

Person, company, and IP enrichment and search on their own key.

Connecting People Data Labs in practice

People Data Labs meters credits by type — enrich, search, search_company, enrich_company, person_identify and others — and once x-totallimit-remaining reaches zero every request returns 402 rather than an empty result. The rate limit is a fixed window set per API key and is never published as a figure, so the only way to learn yours is to read x-ratelimit-limit.minute off a response.

Scopes that draw scrutiny

  • X-Api-Key header The documented header form. There are no scopes: the key that enriches a person can also run searches and spend company credits.
  • api_key URL parameter The documented alternative to the header, which puts the credential into request logs, proxies and browser history.

Rate limits

  • A fixed-window rate limiting strategy, defined on a per-key basis; the figure is account-specific and surfaced in the x-ratelimit-limit.minute response header rather than documented.
  • Credits are tracked per type: enrich, search, search_company, enrich_company, enrich_skill, enrich_job_title, preview_search and person_identify.
  • When x-totallimit-remaining reaches zero, all API requests return 402.

Worth knowing

  • Because the limit is per key and unpublished, a client cannot be written against a constant; it has to read the headers and adapt.
  • Running out of credits is a 402, not a 429, so retry logic keyed on rate-limit codes will hammer a dead key instead of stopping.
  • Keys are requested, rotated and deleted through an account manager or support@peopledatalabs.com rather than self-service, which makes rotation a ticket rather than a script.

Checked against Usage limits (2026-09-29), Authentication (2026-09-29)

Acts as the person, not as itself

Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.

Credentials never touch the agent

Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.

Every call on the record

Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.

What an agent can do

Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.

peopledatalabs_get_v5_autocompleteREAD

Autocomplete a field value via GET /v5/autocomplete. Suggests valid values for a field, for building a query. The same question can be asked with a JSON body by `peopledatalabs_post_v5_autocomplete`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_company_cleanREAD

Clean and standardise a company name via GET /v5/company/clean. Normalises a messy input string to PDL's canonical form. The same question can be asked with a JSON body by `peopledatalabs_post_v5_company_clean`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_company_enrichREAD

Enrich a company record via GET /v5/company/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. The same question can be asked with a JSON body by `peopledatalabs_post_v5_company_enrich`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_company_searchREAD

Search companies via GET /v5/company/search. Returns many records for a query. GET takes SQL or an Elasticsearch query string; the POST form takes the same query as a structured body and is the one to use for anything a URL cannot carry. Supply EXACTLY ONE of `query` (an Elasticsearch 7.7 query, as a JSON string) or `sql` (`SELECT * FROM person|company WHERE ...`); sending both, or neither, is a 400 from People Data Labs naming which. The same question can be asked with a JSON body by `peopledatalabs_post_v5_company_search`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_ip_enrichREAD

Enrich an IP address via GET /v5/ip/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. A 400 here can be DATA rather than an error: an address People Data Labs classifies as infrastructure answers 400 {"error":"Cannot Enrich IP","message":"IP is a Hosting Provider, Proxy, Tor, Relay, or Service"} (measured 2026-09-18 on 8.8.8.8, while 24.5.68.1 answered 200 with a company and a location).

api
peopledatalabs_get_v5_job_title_enrichREAD

Enrich a job title via GET /v5/job_title/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. The same question can be asked with a JSON body by `peopledatalabs_post_v5_job_title_enrich`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_location_cleanREAD

Clean and standardise a location via GET /v5/location/clean. Normalises a messy input string to PDL's canonical form. The same question can be asked with a JSON body by `peopledatalabs_post_v5_location_clean`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_person_enrichREAD

Enrich a person record via GET /v5/person/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. The same question can be asked with a JSON body by `peopledatalabs_post_v5_person_enrich`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_person_identifyREAD

Identify candidate person records via GET /v5/person/identify. Returns several ranked candidate matches rather than one answer -- use it when the identifiers are weak.

api
peopledatalabs_get_v5_person_retrieve_person_idREAD

Retrieve a person record by id via GET /v5/person/retrieve/{person_id}. Fetches a record by its PDL identifier. Costs no credits on a record already purchased. This account cannot call it today: People Data Labs answers HTTP 401 {"type":"Unauthorized","message":"Account <id> has retrieve disabled","billed":false} (measured 2026-09-18). That 401 is an ENTITLEMENT refusal, not a bad key -- the same key answers 200 on enrich, search and the cleaners in the same second -- and it is lifted by buying the Person Retrieve product, not by reconnecting.

api
peopledatalabs_get_v5_person_searchREAD

Search people via GET /v5/person/search. Returns many records for a query. GET takes SQL or an Elasticsearch query string; the POST form takes the same query as a structured body and is the one to use for anything a URL cannot carry. Supply EXACTLY ONE of `query` (an Elasticsearch 7.7 query, as a JSON string) or `sql` (`SELECT * FROM person|company WHERE ...`); sending both, or neither, is a 400 from People Data Labs naming which. The same question can be asked with a JSON body by `peopledatalabs_post_v5_person_search`; reach for that one when a value would not survive a URL.

api
peopledatalabs_get_v5_school_cleanREAD

Clean and standardise a school name via GET /v5/school/clean. Normalises a messy input string to PDL's canonical form. The same question can be asked with a JSON body by `peopledatalabs_post_v5_school_clean`; reach for that one when a value would not survive a URL.

api
peopledatalabs_post_v5_autocompleteREAD

Autocomplete a field value (structured request) via POST /v5/autocomplete. Suggests valid values for a field, for building a query. This is the request-body form of `peopledatalabs_get_v5_autocomplete`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_company_cleanREAD

Clean and standardise a company name (structured request) via POST /v5/company/clean. Normalises a messy input string to PDL's canonical form. This is the request-body form of `peopledatalabs_get_v5_company_clean`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_company_enrichREAD

Enrich a company record (structured request) via POST /v5/company/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. This is the request-body form of `peopledatalabs_get_v5_company_enrich`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_company_searchREAD

Search companies (structured query) via POST /v5/company/search. Returns many records for a query. GET takes SQL or an Elasticsearch query string; the POST form takes the same query as a structured body and is the one to use for anything a URL cannot carry. Supply EXACTLY ONE of `query` (an Elasticsearch 7.7 query, as a JSON string) or `sql` (`SELECT * FROM person|company WHERE ...`); sending both, or neither, is a 400 from People Data Labs naming which. This is the request-body form of `peopledatalabs_get_v5_company_search`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_job_title_enrichREAD

Enrich a job title (structured request) via POST /v5/job_title/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. This is the request-body form of `peopledatalabs_get_v5_job_title_enrich`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_location_cleanREAD

Clean and standardise a location (structured request) via POST /v5/location/clean. Normalises a messy input string to PDL's canonical form. This is the request-body form of `peopledatalabs_get_v5_location_clean`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_person_enrichREAD

Enrich a person record (structured request) via POST /v5/person/enrich. Returns the single best-matching record for the identifiers supplied; answers 404 when nothing matches confidently. This is the request-body form of `peopledatalabs_get_v5_person_enrich`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_person_retrieve_bulkREAD

Retrieve several person records by id via POST /v5/person/retrieve/bulk. Fetches a record by its PDL identifier. Costs no credits on a record already purchased. This account cannot call it today: People Data Labs answers HTTP 401 {"type":"Unauthorized","message":"Account <id> has bulk retrieve disabled","billed":false} (measured 2026-09-18). That 401 is an ENTITLEMENT refusal, not a bad key, and is lifted by buying the Person Retrieve product rather than by reconnecting.

api
peopledatalabs_post_v5_person_searchREAD

Search people (structured query) via POST /v5/person/search. Returns many records for a query. GET takes SQL or an Elasticsearch query string; the POST form takes the same query as a structured body and is the one to use for anything a URL cannot carry. Supply EXACTLY ONE of `query` (an Elasticsearch 7.7 query, as a JSON string) or `sql` (`SELECT * FROM person|company WHERE ...`); sending both, or neither, is a 400 from People Data Labs naming which. This is the request-body form of `peopledatalabs_get_v5_person_search`: the same operation, with every input sent as a JSON field instead of a query parameter.

api
peopledatalabs_post_v5_school_cleanREAD

Clean and standardise a school name (structured request) via POST /v5/school/clean. Normalises a messy input string to PDL's canonical form. This is the request-body form of `peopledatalabs_get_v5_school_clean`: the same operation, with every input sent as a JSON field instead of a query parameter.

api

Put People Data Labs behind one governed endpoint.

Same permissions, same audit trail, whatever else you connect next.