Apollo has no radius parameter in its API. ZoomInfo offers five fixed buckets. Sales Navigator implies 100 miles. A look at how B2B databases handle geography.

Apollo's search API has no radius parameter at all. Not on people search, not on organization search, not in any form: no radius, no ZIP, no postal code, no latitude and longitude. The only geography those endpoints accept is a named place, which Apollo's own documentation illustrates with examples like california, tokyo, and spain. Radius exists in Apollo's web interface, but only as three fixed buckets, and ZoomInfo's radius options sit behind a login wall that returns 401 to anyone who tries to read the help article directly.

TL;DR

Apollo's people-api-search and organization-search endpoints expose zero radius parameters. person_locations[] takes "cities, US states, and countries" and organization_locations[] takes an HQ location in the same named-place format.
Apollo's UI radius has exactly three settings: 50, 100, and 300 miles, with no radius applied by default (knowledge.apollo.io article 4412665755661).
Apollo's UI radius only works on net new records. The help doc states it applies "for net new people and companies," so it cannot be retroactively applied to records already saved in your Apollo account.
ZoomInfo is reported to offer 10, 25, 50, 100, and 250 mile radius options around a ZIP code. These figures come from search-engine snippets of the official help pages, which are login-gated and could not be opened directly.
LinkedIn Sales Navigator's radius dropdown values are undocumented. The one official number anywhere in LinkedIn's help center is "an implied 100-mile radius to any Location selection you make" (Sales Navigator help a417339).

The comparison table

Here is every radius capability we could verify, along with how confident we are in each row and where the number came from.

Product	Where radius lives	Options	Min	Max	Applies to saved records?	Source confidence
Apollo search API	Nowhere	None	n/a	n/a	n/a	High. Official parameter lists read directly
Apollo web UI	UI filter only	50, 100, 300 miles	50 mi	300 mi	No, net new records only	High. Official help article read directly
Apollo Google Maps importer	Separate tool, distance-sorted	No radius setting, capped result count	n/a	n/a	n/a	High. Official help article read directly
ZoomInfo	UI filter around a ZIP	10, 25, 50, 100, 250 miles	10 mi	250 mi	Unverified	Medium-high. Login-gated help pages, snippets only
LinkedIn Sales Navigator	Location filter, implied	Undocumented dropdown values	Unknown	Unknown	Unknown	Low for the dropdown, high for the 100-mile statement

Two things stand out. First, only one of these products puts radius anywhere near its API, and that product is not Apollo. Second, the minimum radius any of them is documented to support is ten miles, and that is the vendor with the least verifiable documentation.

What Apollo's search API actually accepts

Apollo publishes parameter lists for both of its core search endpoints, and both are unambiguous about geography. person_locations[] is described as "the location where people live," and the accepted granularity is spelled out in the same sentence: "You can search across cities, US states, and countries." organization_locations[] covers a company's headquarters location and uses the same named-place format. The documented examples are literally strings like california, tokyo, and spain.

What is absent matters more than what is present. There is no radius parameter. There is no postal_code or zip parameter. There is no latitude or longitude pair. There is no bounding box. If you are building against Apollo programmatically and your requirement is "everyone within 20 miles of this address," the API gives you no expression for that requirement. You can ask for a city. You can ask for a state. You cannot ask for a circle.

The practical consequence is that any distance logic has to be reconstructed on your side, after the fact, and it has to be reconstructed from data the API does not necessarily return in a geocodable form. You would pull a city, then post-filter, then discover that "Springfield" is ambiguous and that a company's HQ city is not where its service technicians actually work. For a lot of B2B use cases this never comes up, because the query really is "software companies in California." For anything where physical proximity is the qualifying criterion, the mismatch surfaces immediately.

Geography input	Accepted by Apollo's search APIs?	Notes
City name	Yes	Documented example: `tokyo`
US state	Yes	Documented example: `california`
Country	Yes	Documented example: `spain`
ZIP or postal code	No	No such parameter on either endpoint
Latitude and longitude	No	No coordinate parameters documented
Radius in miles or km	No	Radius exists only in the web UI, never in the API parameter list

It is worth being precise about scope here. This is a statement about Apollo's documented public search parameters, not a claim that Apollo is missing something it promised. Apollo never promised radius in the API. The docs are consistent with the product's design.

Apollo's UI radius: three buckets, net new only

Radius does exist inside Apollo's web interface, and Apollo documents it in knowledge.apollo.io article 4412665755661. The full set of choices is 50 miles, 100 miles, and 300 miles. The default is none, meaning no radius is applied unless you deliberately pick one.

Fifty miles is a large circle. It covers roughly 7,850 square miles of land, which in most metros means several counties and a good chunk of the surrounding exurbs. If your qualifying question is whether a prospect is close enough for a same-day site visit, fifty miles is not a filter, it is a rounding error in your favor. You will get everyone you wanted plus a large multiple of people you did not.

The second constraint in Apollo's help documentation is the one most people miss. The radius filter applies, in Apollo's own words, "for net new people and companies." It does not retroactively apply to records already saved in your Apollo account. So the filter is a discovery-time control rather than a general query control. If you already imported ten thousand contacts and now want to know which of them fall inside a circle, the UI radius will not answer that question for you. You are back to exporting and computing distance yourself.

Neither of these is a defect. Fifty, one hundred, and three hundred mile buckets are perfectly sensible increments for territory planning at a regional or multi-state level, which is what a lot of enterprise sales organizations are actually doing when they draw a circle. A rep covering the Southeast does not care about twenty miles. The buckets match the job the tool was designed for.

The Maps importer is the tell

The most interesting thing in Apollo's documentation is not a limitation, it is a separate product surface. Apollo ships a Google Maps importer, documented in article 44340555852685, and that tool behaves nothing like the core database.

In the Maps importer, results are, per Apollo's official wording, "ordered by distance from your search location." Each result row displays a specific set of fields: "Company Name, Distance, Company Address, Rating, Review Count, Company Website." Distance is not a filter you apply, it is a column you read and a sort order you get by default. The tool is capped at 20, 40, or 60 results per search.

Read those two designs next to each other. In the core database, geography is a named place you select from a list and distance is invisible. In the Maps importer, geography is a point, distance is the primary sort key, and distance is printed on every row alongside a street address, a star rating, and a review count. Those are not two views of the same data model. They are two different data models, aimed at two different buyers.

Apollo, in other words, reached the same conclusion this post is arguing: when the record is a local business, the useful presentation is distance-sorted and distance-labeled, with the physical address and the reputation signals in view. What Apollo did with that conclusion is the notable part. It did not add radius to organization-search. It built a separate importer, with a result cap in the dozens, sitting next to the core database rather than inside it.

The result cap deserves a note too. Twenty to sixty results per search is a reasonable ceiling for a person browsing a map. It is a very low ceiling for building a territory list of every qualifying business in a metro area. The cap is another signal about intended use: this is a lookup tool, not a list-building engine.

ZoomInfo: five buckets, behind a login wall

ZoomInfo's radius options are reported as 10, 25, 50, 100, and 250 miles, applied around a ZIP code. We want to be careful about how much weight that sentence carries.

We could not open ZoomInfo's help documentation. Every fetch of help.zoominfo.com returns a 401. The public shell is a Salesforce single-page application that requires authentication before it will render article content, so there is no way to read the source page without a ZoomInfo login. What we have instead are three independent search-engine snippets of the official help pages, all of which report the same five values verbatim. Three consistent independent extractions of the same official source is decent evidence, and it is why we call this medium-high rather than low. It is not the same as reading the page.

ZoomInfo's public marketing pages, which are readable, say only "Search by zip code, city, or radius." That confirms radius exists and confirms the ZIP-centered model, but it publishes no values.

Two related details remain unverified. We do not know ZoomInfo's default radius, meaning whether a radius is applied automatically when you enter a ZIP or whether, as in Apollo, the default is off. And we do not know whether ZoomInfo displays a per-result distance the way Apollo's Maps importer does. Both of those change how the feature feels in daily use, and neither is answerable from outside the login wall.

Taking the reported figures at face value, ZoomInfo has the widest published range of the three: a 10-mile floor is genuinely tighter than anything Apollo's UI offers, and 250 miles at the top covers multi-state territory planning. Anchoring on a ZIP rather than a city is also a meaningfully different design choice, because a ZIP is a much smaller and more precise unit than a city, especially in dense metros where a single city name spans dozens of them.

Sales Navigator: one official number, and it is not a dropdown

LinkedIn Sales Navigator is the case where the popular answer and the documented answer diverge the most.

You will find a 10, 25, 50, 75, 100 mile list quoted for Sales Navigator in many places. We could not find it in any reachable official source. Four official LinkedIn help articles were checked, including both of the filter-definition pages (a1452817 and a1463448). All of them describe the location filter the same way: "Filter by region, country, state/province, city or postal code." Radius is not mentioned in any of them. Not the values, not the control, not the concept.

The single official radius statement anywhere in LinkedIn's Sales Navigator help center is this, from answer a417339: "There is an implied 100-mile radius to any Location selection you make."

That sentence is doing something quite different from a dropdown. It is not a filter you set, it is a behavior of the platform. Any location you pick is already fuzzed outward by roughly a hundred miles, whether you wanted that or not. If you select a city, you are not getting that city. You are getting that city plus a hundred-mile halo, and there is no documented control to tighten it.

For its actual purpose that is a defensible default. Professional profiles list a metro, people commute, people relocate, and a person who lists a suburb and a person who lists the nearby major city are often the same market. A hard boundary at the city line would silently drop real prospects. A hundred-mile halo makes the recall problem go away, at the cost of precision no one was measuring anyway. Sales Navigator's unit of record is a person's professional identity, not a service address, and the geography model follows from that.

We are flagging the undocumented status deliberately rather than repeating the widely-quoted list, because a filter that might not exist is a different planning input than a filter that definitely exists with known values.

Why named-place geography is the right design here

None of this makes these products bad. It makes them built for a different unit of geography, and it is worth spelling out why that unit is the correct one for the buyer they serve.

A B2B contact database's unit of record is a person at a company. A company has a headquarters, that headquarters is in a city, and the city is a stable, canonical, joinable string. Everything downstream works cleanly on that model. You can dedupe on it, you can roll it up to state and country, you can slice territories on it, and you never have to geocode anything. When you are selling to a VP of Engineering at a 200-person software company, the HQ city is genuinely the right granularity, because the deal does not depend on how far anyone drives. It is a video call. The relevant geography is time zone and legal jurisdiction, not distance.

The model bends when the record stops being a person at a company and becomes a business at an address. A plumbing contractor's buying question is not "which companies are headquartered in Phoenix." It is "who is within twenty minutes of my van." That question needs a point, a distance, and a per-row distance value to sort and triage by. City strings cannot express it. A fifty-mile bucket cannot express it either, since fifty miles in a metro is an hour and a half of traffic in the wrong direction.

Apollo's own architecture is the clearest evidence that this is a real distinction rather than a rhetorical one. Given local businesses to handle, Apollo did not extend organization-search with a radius parameter. It built a separate Google Maps importer, sorted by distance, with a Distance column on every row, a street address, a star rating, and a review count. Those extra columns are not decoration. Rating and review count are the local-business equivalent of firmographics, standing in for headcount and funding stage. The importer is a small second product with a second data model, living beside the first one.

Local coverage and B2B contact coverage are genuinely different problems, and a tool optimized for one will show its seams on the other. That is a capability observation about how these databases are shaped, not a verdict on their quality. If your motion is enterprise or mid-market SaaS, the named-place model is not a compromise you are tolerating. It is the correct abstraction and you should be glad nobody made you geocode anything.

Frequently Asked Questions

Does Apollo's API support radius search?

No. Neither people-api-search nor organization-search exposes a radius parameter, and neither accepts a ZIP code, a postal code, or latitude and longitude coordinates. The only geography inputs documented are person_locations[] and organization_locations[], both of which take named places at city, US state, or country granularity. Apollo's documented examples are strings like california, tokyo, and spain. Any distance logic has to be built on your side after the results come back.

What radius options does Apollo's web interface offer?

Three: 50 miles, 100 miles, and 300 miles. The default is no radius at all, so nothing is applied unless you pick a value. Apollo documents this in knowledge base article 4412665755661. There is no option below 50 miles, which means the tightest circle Apollo's UI can draw still covers roughly 7,850 square miles.

Can Apollo's radius filter be applied to contacts I already saved?

No. Apollo's help documentation states that the radius filter applies "for net new people and companies," which excludes records already saved in your Apollo account. It is a discovery-time control rather than a general query filter. To evaluate distance across an existing saved list, you would need to export the records and compute distance yourself.

What radius options does ZoomInfo offer?

ZoomInfo is reported to offer 10, 25, 50, 100, and 250 miles around a ZIP code. We want to be precise about the sourcing: help.zoominfo.com returns 401 to every fetch because the public shell is a login-gated Salesforce single-page application, so we could not open the official article directly. Those five values come from three independent search-engine snippets of the official help pages, all agreeing verbatim. ZoomInfo's public marketing page confirms only that you can "Search by zip code, city, or radius." The default radius and whether ZoomInfo shows a per-result distance both remain unverified.

Does LinkedIn Sales Navigator have a radius filter?

The dropdown values commonly quoted for Sales Navigator do not appear in any official source we could reach, including both of LinkedIn's filter-definition help articles, which describe the location filter only as "region, country, state/province, city or postal code." Treat the popular 10 to 100 mile list as undocumented. The one official radius statement is that "There is an implied 100-mile radius to any Location selection you make," which is a platform behavior applied automatically rather than a control you configure.

Which of these is best for finding local businesses near an address?

None of the core databases are shaped for that question, and Apollo effectively said so by building a separate Google Maps importer instead of adding radius to its core API. In that importer, results are "ordered by distance from your search location" and each row shows Company Name, Distance, Company Address, Rating, Review Count, and Company Website, with a cap of 20, 40, or 60 results per search. That is a lookup surface rather than a list-building engine. Local coverage and B2B contact coverage are different problems, and the tools reflect it.

Last updated July 2026.

Radius Search in B2B Databases: What Apollo and ZoomInfo Support