Skip to main content
Glama

AIsa Apollo

People API Search

post_apollo_mixed_people_api_search
Read-onlyIdempotent

Use the People API Search endpoint to find net new people in the Apollo database. Several filters are available to help narrow your search. This endpoint is optimized for API usage and does not consume credits. This endpoint is primarily designed for prospecting net new people. This endpoint does not return email addresses or phone numbers. Use the People Enrichment or Bulk People Enrichment endpoints to enrich data. This endpoint requires a master API key. Refer to Create API Keys to learn how to create a master API key. To protect Apollo's performance for all users, this endpoint has a display limit of 50,000 records (100 records per page, up to 500 pages). Add more filters to narrow your search results as much as possible. This limitation does not restrict your access to Apollo's database; you just need to access the data in batches.

Published reference price: $0.012 USD per successful request. Account-specific pricing and final settlement may differ.

Input Schema

NameRequiredDescriptionDefault
pageNoThe page number of the Apollo data that you want to retrieve. Use this parameter in combination with the per_page parameter to make search results for navigable and improve the performance of the endpoint. Example: 4
per_pageNoThe number of search results that should be returned for each page. Limiting the number of results per page improves the endpoint's performance. Use the page parameter to search the different pages of data. Example: 10
q_keywordsNoA string of words over which we want to filter the results.
person_titlesNoJob titles held by the people you want to find. For a person to be included in search results, they only need to match 1 of the job titles you add. Adding more job titles expands your search results. Results also include job titles with the same terms, even if they are not exact matches. For example, searching for marketing manager might return people with the job title content marketing manager. Use this parameter in combination with the person_seniorities[] parameter to find people based on specific job functions and seniority levels. Examples: sales development representative; marketing manager; research analyst
organization_idsNoThe Apollo IDs for the companies (employers) you want to include in your search results. Each company in the Apollo database is assigned a unique ID. To find IDs, call the Organization Search endpoint and identify the values for organization_id. Example: 5e66b6381e05b4008c8331b8
person_locationsNoThe location where people live. You can search across cities, US states, and countries. To find people based on the headquarters locations of their current employer, use the organization_locations parameter. Examples: california; ireland; chicago
revenue_range_maxNoThe maximum revenue the person's current employer generates. Use this parameter in combination with revenue_range[min] to set a revenue range. Do not enter currency symbols, commas, or decimal points in the figure. Examples: 500000; 1500000
revenue_range_minNoThe minimum revenue the person's current employer generates. Use this parameter in combination with revenue_range[max] to set a revenue range. Do not enter currency symbols, commas, or decimal points in the figure. Examples: 500000; 1500000
person_senioritiesNoThe job seniority that people hold within their current employer. This enables you to find people that currently hold positions at certain reporting levels, such as Director level or senior IC level. For a person to be included in search results, they only need to match 1 of the seniorities you add. Adding more seniorities expands your search results. Searches only return results based on their current job title, so searching for Director-level employees only returns people that currently hold a Director-level title. If someone was previously a Director, but is currently a VP, they would not be included in your search results. Use this parameter in combination with the person_titles[] parameter to find people based on specific job functions and seniority levels. The following options can be used for this parameter: owner founder c_suite partner vp head director manager senior entry intern
contact_email_statusNoThe email statuses for the people you want to find. You can add multiple statuses to expand your search. The statuses you can search include: verified unverified likely to engage unavailable
include_similar_titlesNoThis parameter determines whether people with job titles similar to the titles you define in the person_titles[] parameter are returned in the response. Set this parameter to false when using person_titles[] to return only strict matches for job titles.
organization_locationsNoThe location of the company headquarters for a person's current employer. You can search across cities, US states, and countries. If a company has several office locations, results are still based on the headquarters location. For example, if you search chicago but a company's HQ location is in boston, people that work for the Boston-based company will not appear in your results, even if they match other parameters. To find people based on their personal location, use the person_locations parameter. Examples: texas; tokyo; spain
q_organization_job_titlesNoThe job titles that are listed in active job postings at the person's current employer. Examples: sales manager; research analyst
organization_job_locationsNoThe locations of the jobs being actively recruited by the person's employer. Examples: atlanta; japan
q_organization_domains_listNoThe domain name for the person's employer. This can be the current employer or a previous employer. Do not include www., the @ symbol, or similar. This parameter accepts up to 1,000 domains in a single request. Examples: apollo.io; microsoft.com
organization_num_jobs_range_maxNoThe maximum number of job postings active at the person's current employer. Use this parameter in combination with organization_num_jobs_range[min] to set a job postings range. Examples: 50; 500
organization_num_jobs_range_minNoThe minimum number of job postings active at the person's current employer. Use this parameter in combination with organization_num_jobs_range[max] to set a job postings range. Examples: 50; 500
organization_num_employees_rangesNoThe number range of employees working for the person's current company. This enables you to find people based on the headcount of their employer. You can add multiple ranges to expand your search results. Each range you add needs to be a string, with the upper and lower numbers of the range separated only by a comma. Examples: 1,10; 250,500; 10000,20000
organization_job_posted_at_range_maxNoThe latest date when jobs were posted by the person's current employer. Use this parameter in combination with organization_job_posted_at_range[min] to set a date range for when jobs posted. Example: 2025-09-25
organization_job_posted_at_range_minNoThe earliest date when jobs were posted by the person's current employer. Use this parameter in combination with organization_job_posted_at_range[max] to set a date range for when jobs posted. Example: 2025-07-25
currently_using_all_of_technology_uidsNoFind people based on all of the technologies their current employer uses. Apollo supports filtering by 1,500+ technologies. Apollo calculates technologies data from multiple sources. This data is updated regularly. Check out the full list of supported technologies by downloading this CSV file . Use underscores (_) to replace spaces and periods for the technologies listed in the CSV file. Examples: salesforce; google_analytics; wordpress_org
currently_using_any_of_technology_uidsNoFind people based on any of the technologies their current employer uses. Apollo supports filtering by 1,500+ technologies. Apollo calculates technologies data from multiple sources. This data is updated regularly. Check out the full list of supported technologies by downloading this CSV file . Use underscores (_) to replace spaces and periods for the technologies listed in the CSV file. Examples: salesforce; google_analytics; wordpress_org
currently_not_using_any_of_technology_uidsNoExclude people from your search based on any of the technologies their current employer uses. Apollo supports filtering by 1,500+ technologies. Apollo calculates technologies data from multiple sources. This data is updated regularly. Check out the full list of supported technologies by downloading this CSV file . Use underscores (_) to replace spaces and periods for the technologies listed in the CSV file. Examples: salesforce; google_analytics; wordpress_org

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changed
    • removedInput schema / properties / organization_job_posted_at_range
      Removed value: -{
      -  "properties": {
      -    "max": {
      -      "description": "The latest date when jobs were posted by the person's current employer. Use this parameter in combination with organization_job_posted_at_range[min] to set a date range for when jobs posted. Example: 2025-09-25",
      -      "type": "string"
      -    },
      -    "min": {
      -      "description": "The earliest date when jobs were posted by the person's current employer. Use this parameter in combination with organization_job_posted_at_range[max] to set a date range for when jobs posted. Example: 2025-07-25",
      -      "type": "string"
      -    }
      -  },
      -  "type": "object"
      -}
    • addedInput schema / properties / organization_job_posted_at_range_max
      Added value: +{
      +  "description": "The latest date when jobs were posted by the person's current employer. Use this parameter in combination with organization_job_posted_at_range[min] to set a date range for when jobs posted. Example: 2025-09-25",
      +  "type": "string"
      +}
    • addedInput schema / properties / organization_job_posted_at_range_min
      Added value: +{
      +  "description": "The earliest date when jobs were posted by the person's current employer. Use this parameter in combination with organization_job_posted_at_range[max] to set a date range for when jobs posted. Example: 2025-07-25",
      +  "type": "string"
      +}
    • removedInput schema / properties / organization_num_jobs_range
      Removed value: -{
      -  "properties": {
      -    "max": {
      -      "description": "The maximum number of job postings active at the person's current employer. Use this parameter in combination with organization_num_jobs_range[min] to set a job postings range. Examples: 50; 500",
      -      "type": "integer"
      -    },
      -    "min": {
      -      "description": "The minimum number of job postings active at the person's current employer. Use this parameter in combination with organization_num_jobs_range[max] to set a job postings range. Examples: 50; 500",
      -      "type": "integer"
      -    }
      -  },
      -  "type": "object"
      -}
    • addedInput schema / properties / organization_num_jobs_range_max
      Added value: +{
      +  "description": "The maximum number of job postings active at the person's current employer. Use this parameter in combination with organization_num_jobs_range[min] to set a job postings range. Examples: 50; 500",
      +  "type": "integer"
      +}
    • addedInput schema / properties / organization_num_jobs_range_min
      Added value: +{
      +  "description": "The minimum number of job postings active at the person's current employer. Use this parameter in combination with organization_num_jobs_range[max] to set a job postings range. Examples: 50; 500",
      +  "type": "integer"
      +}
    • removedInput schema / properties / revenue_range
      Removed value: -{
      -  "properties": {
      -    "max": {
      -      "description": "The maximum revenue the person's current employer generates. Use this parameter in combination with revenue_range[min] to set a revenue range. Do not enter currency symbols, commas, or decimal points in the figure. Examples: 500000; 1500000",
      -      "type": "integer"
      -    },
      -    "min": {
      -      "description": "The minimum revenue the person's current employer generates. Use this parameter in combination with revenue_range[max] to set a revenue range. Do not enter currency symbols, commas, or decimal points in the figure. Examples: 500000; 1500000",
      -      "type": "integer"
      -    }
      -  },
      -  "type": "object"
      -}
    • addedInput schema / properties / revenue_range_max
      Added value: +{
      +  "description": "The maximum revenue the person's current employer generates. Use this parameter in combination with revenue_range[min] to set a revenue range. Do not enter currency symbols, commas, or decimal points in the figure. Examples: 500000; 1500000",
      +  "type": "integer"
      +}
    • addedInput schema / properties / revenue_range_min
      Added value: +{
      +  "description": "The minimum revenue the person's current employer generates. Use this parameter in combination with revenue_range[max] to set a revenue range. Do not enter currency symbols, commas, or decimal points in the figure. Examples: 500000; 1500000",
      +  "type": "integer"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent/open-world, and the description adds substantial non-obvious behavior: no credit consumption, master API key requirement, a 50,000-record display limit (100/page, 500 pages), and guidance to narrow with filters. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and key exclusions are front-loaded, but there is mild redundancy from the repeated 'This endpoint...' construction across consecutive sentences. It is appropriately sized for a 23-parameter tool, just slightly repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and full annotation coverage, the description still supplies everything an agent needs to call it correctly: auth requirement, credit behavior, pagination ceiling, and enrichment alternatives. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across 23 parameters, so the schema already documents each filter in depth. The description adds no per-parameter syntax or pairing guidance beyond the pagination limit note, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('find net new people in the Apollo database') and explicitly contrasts the tool with People Enrichment / Bulk People Enrichment, so an agent can distinguish it from siblings like post_apollo_people_match without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the primary use case (prospecting net new people), the explicit exclusion ('does not return email addresses or phone numbers'), and names the alternative endpoints to use for enrichment. This is an explicit when/when-not/alternative routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources