B2B People and Company Search API - GTM Database

Ask one question that reaches from a person to their employer and back. Current software engineers at companies over five hundred people running a particular vendor, in one expression. One flat row per record.

What this actor does

• Searches across entities, not within one. The query language lets a people search test facts about the employer, and a company search test facts about the staff. select from people where experiences.any(is_current = true and job_title is_similar_to ("engineer") and company.technographics.any(vendor = "Salesforce")) is a single query. A filter list cannot express that, which is why this is the default mode.
• Passes your query through untouched. Nested parentheses, and, or, not, similarity matching and cross-entity clauses all reach the provider exactly as written. Nothing here rewrites, quotes or splits a query, because the provider validates it far better than this actor could and a rewritten boolean expression is a silently different search.
• Writes out the vocabulary rather than guessing it. This provider serves its filter names at run time rather than publishing them, and they change. Two modes exist purely to fetch that: one writes every accepted filter for people or companies into the dataset with its type, allowed values and usage guidance, the other writes out the query language grammar. Run one, read the result, then build your search from names that actually exist.
• Drains a search properly. A search here is created once and then pulled from a stateful iterator: there is no page number, and the only honest signal that more remain is the flag the provider returns. The run reads that flag rather than inferring the end from a short page.
• Tells you when the provider stopped early. There is a difference between a search that ran out of matching records and one the provider capped at your plan's query limit, and only one of them means you have seen everything. The run says which happened.
• Runs your own saved routines. Point it at a provider-managed enrichment function or a custom function from your workspace, give it rows of input values, and it runs them in batches, waits for the asynchronous work, and writes one row per item with the result or the reason it failed. Your own id on a row comes back with the result so it ties to your record.
• Treats work in progress as progress. The routine endpoint answers with an in-progress status while it works. Reading that as a failure is the usual way an integration with this provider reports a successful empty run; this one polls until the work is actually done.
• Reports what your allowance has left. The provider returns the period quota alongside the data, and the run logs what remains and when it resets.
• Never charges for a miss. Only rows carrying a resolved record are billed.

Input

Field	What it does
mode	Advanced query, structured filters, filter fields, query reference, or routine.
sourceType	People or companies, for the filters and fields modes.
searchQuery	The query, in the provider's own language.
filters	A JSON filters object, for structured filters mode.
jobTitleKeywords	Shortcut for the job title filter.
locationCities	Shortcut for the city filter.
companyIndustries	Shortcut for the company industry filter.
routineId	Which enrichment function to run.
routineItems	The rows to run it over.
requireLinkedinUrl	Keep only rows with a profile URL.
requireCompanyDomain	Keep only companies with a domain.
countries	Keep only these countries.
reportWorkspace	Log which workspace the key belongs to.
pageSize	Records drawn per request, up to 500.
requestsPerMinute	Pace the run under your plan's rate limit.
routineTimeoutMinutes	Give up waiting for a routine batch.
skipNotFound	Leave misses and refusals out of the dataset.
maxResults	Hard cap on rows, and therefore on spend.
apiKey	Your own API key. Stored as a secret.

Example output

{
  "found": true,
  "mode": "query",
  "recordType": "person",
  "personId": 42,
  "fullName": "Jane Doe",
  "firstName": "Jane",
  "lastName": "Doe",
  "linkedinUrl": "https://www.linkedin.com/in/example",
  "jobTitle": "Software Engineer",
  "companyName": "Example Corp",
  "jobStartDate": "2024-01-01",
  "jobEndDate": null,
  "jobLocation": "New York, New York, United States",
  "locationName": "New York, New York, United States",
  "city": "New York",
  "state": "New York",
  "country": null,
  "matchedExperiences": [
    {
      "company": "Example Corp",
      "title": "Software Engineer",
      "location": "New York, New York, United States",
      "startDate": "2024-01-01",
      "endDate": null
    }
  ],
  "error": null,
  "raw": { }
}

Frequently asked questions

What can the query language do that a filter list cannot?

Reach across entities and nest logic. A filter list can say "job title contains engineer" and "company has over 500 employees" as two independent conditions. The query language can say "has a current experience whose title is similar to engineer at a company that has over 500 employees and uses this vendor", which is one condition about one experience rather than three conditions that happen to be true of the same person. It also takes parentheses, so alternatives can be grouped inside a requirement: two acceptable titles, but only at companies of a certain size.

How do I learn the fields I can query?

Run the query reference mode. It fetches the provider's own grammar and field reference with your key and writes it into the dataset, so you can read exactly what is queryable rather than guessing. For the older structured filters mode, run the filter fields mode instead: it writes out every accepted filter name for people or for companies, with its type, its allowed values and the provider's guidance on how it behaves.

Why does the actor not just list the filters in its own input form?

Because this provider does not publish them. The filter vocabulary is served at run time, per record type, and it changes. Hard-coding a list of plausible filter names would produce a search that quietly ignored half of them, which is worse than asking you to look them up: an ignored filter widens your search and you pay for the extra rows without ever being told. Three filter names appear in the provider's own documented examples and are offered as convenience fields; everything else goes through the filters object.

What is the difference between the two search modes?

The advanced query is newer, in beta, and far more expressive. Structured filters are the older JSON form, still supported, and the right choice if you already have filter objects saved from somewhere else or you want a simple keyword-and-location search. They hit different endpoints and both are here.

What does has_more actually mean, and why does it matter?

The search endpoint is an iterator with state at the provider. Each page comes back with a flag saying whether more remain. That flag is the only reliable stopping condition: a short page does not mean the end, and there is no total to count against. This actor reads the flag, and when the provider stops for its own reasons rather than because the results ran out, it says so, because "your plan will not return more this period" and "there are no more" look identical in an empty page.

What is a routine and why would I run one here?

A routine is saved logic in your own workspace: a provider-managed enrichment function, or a custom function you built. Running it through this actor means you can point it at a list of rows, have the batching, the waiting and the retrying handled, and get one dataset row per item with either the result or the reason it failed. Your own id on an input row comes back attached to its result, so the output joins straight back to your records.

Do the search results include email addresses?

No. This provider's search returns profile and firmographic data; contact details come from its enrichment routines, which are a separate call with their own cost. That separation is the provider's own and this actor keeps it, so a search is never billed as an enrichment. Use the routine mode with an enrichment function when you want contact details for the rows you kept.

Are the routes in this actor verified against the live service?

They come from the provider's own published API document rather than from probing, and that is worth saying plainly. This provider's gateway checks the credential before it decides whether a path exists, so a wrong key and an invented route both answer the same way and probing proves nothing about either. Everywhere that probing can distinguish them, it is used; here it cannot, so the published document is the source.

Do I need my own API key?

Yes. This actor does not include data access. You use your own key from Clay, the provider whose go-to-market database API this actor calls, created under Settings, then Account, then API keys in your workspace, and pasted into the apiKey field, where it is stored as an Apify secret. It travels in a request header and is never written to the log. Your own plan, allowance and terms apply, and some parts of this API are limited to particular plans.

How much does a run cost?

Pricing is pay per result: you are charged for each record resolved into the dataset, and never for items the provider returned nothing for, for inputs refused before they were sent, for rows dropped by the filters, or for duplicates. Apify platform usage is included in the per-result price. Your own provider allowance is separate and billed by them.

Keyword map

B2B people search API, company search API, GTM database, go to market data, cross entity search, boolean search query language, prospect search API, account search API, firmographic data, technographic search, employee count filter, annual revenue data, total funding data, job title search, seniority search, enrichment routine, waterfall enrichment automation, sales intelligence API, lead list building, ICP account list, CRM enrichment pipeline, contact data enrichment, agent accessible data API, headless GTM workflow