Buzzfile Search by Name or a Company API: One Name, Ten Companies
One free call on the name Patagonia returned ten companies, all called Patagonia. A rival fuzzy search returned two, and neither was the right one.
Copy this line to your agent to resolve a company name into a record.
set up https://monid.ai/SKILL.md and use hunterio /domain-finder then /companies/find
On 2026-09-17 we searched one company name, Patagonia, through five routes in one minute. A free call returned ten companies, every one of them called Patagonia. A second free call returned exactly one. A paid fuzzy search with relevance scoring returned two companies, and neither of them was the clothing company everybody means. That spread is the whole subject of this guide, which runs through Monid, the OpenRouter for agent tools.
What does Buzzfile search by name actually do?
It looks a business up in a US directory using its name, and returns a profile page: address, phone, industry code, size band, sometimes an executive list. We do not resell Buzzfile and this article measures nothing about it. What it is worth saying is what the job underneath it is, because that job has more than one shape.
Three different questions wear the same words
Which company is this? You have a name and need to know which legal entity, which domain, which one of the several that share the name. This is disambiguation, and it is where most name searches actually fail.
What is this company? You already know which one. You want the record: industry, size, location, technology, parent company.
Who is at this company? You want people, which is a different product entirely and the subject of the prospecting guide.
A directory bundles the three behind one search box. An API pulls them apart, and once they are apart you can see that the first one is free and the third one is where the money goes.
Why the first question is the hard one
Because names are not identifiers. The measurement below is a plain demonstration: one ordinary company name, ten live companies carrying it, and only one field on a free endpoint that tells them apart.
📖 See also Best API to Search a Company's Homepage From Its Name
Why did one name return ten companies?
Because ten companies are called Patagonia, and a name search is obliged to return all of them.
The free call that shows the problem
hunterio/domain-finder with company: "Patagonia" and limit: 10, billed at nothing:
email_count domain company_name
1320 patagonia.com Patagonia
12 patagonia.com.au Patagonia
9 patagonia.com.ar Patagonia
5 patagonia.agency Patagonia
3 patagonia.co.za Patagonia
3 patagonia.co.nz Patagonia
2 patagonia.com.pl Patagonia
1 patagonia.at Patagonia
0 patagonia.travel Patagonia
0 patagonia.no Patagonia
Ten rows, one name, meta.results: 10. The company_name field is identical on every row and therefore useless. The field that actually separates them is email_count, which spans 1,320 down to 0.
That count is the disambiguator
A company with 1,320 known addresses is an organisation of a certain size. A company with zero is a parked domain or a two-person shop. You do not need a second request, a scoring model or a paid record to pick the right Patagonia out of ten. You need one free call and one integer.
This is the same shape as the free-search-then-paid-reveal pattern measured across three prospecting providers in the prospecting guide: the cheap call carries the signal that decides what to buy.
The other free call resolves instead of listing
hunterio/discover with organization: {name: ["Patagonia"]} returned meta.results: 1, a single row for patagonia.com with emails_count: {personal: 1235, generic: 85, total: 1320}. The interesting part was in the response metadata: meta.filters came back as {organization: {domain: ["patagonia.com"]}}. It had quietly rewritten the name filter into a domain filter before running the query.
Two free endpoints on one provider, two opposite behaviours. One hands you the ambiguity, the other resolves it and does not tell you there was any. Knowing which one you called matters more than the price, because both are free.
How do you look up a company by name through one key?
Three steps, and the first two cost nothing.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add -k <your-api-key> -l main
Step 1. Turn the name into candidate domains, free
What it does. Returns every domain matching the name, with a size signal on each.
The endpoints. hunterio/domain-finder, free, takes company, limit up to 10 and perfect_match.
monid run -p hunterio -e /domain-finder --query '{"company": "Patagonia", "limit": 10}'
What comes back. Up to ten candidates with email_count. Set perfect_match: true when you want one confident answer instead of a list, and leave it false when you would rather see the ambiguity you are about to resolve silently.
Step 2. Read the record, paid
What it does. Turns the chosen domain into the firmographic record a directory page would show you.
The endpoints. hunterio/companies/find, per call, takes domain.
monid run -p hunterio -e /companies/find --query '{"domain": "patagonia.com"}'
What comes back. Thirty-four fields on our run: legalName, description, foundedYear 1973, location, geo, timeZone, a category block carrying GICS, SIC and NAICS codes at once, metrics with employeesCount 3780 and an employees band of 1K-5K, a tech array of thirteen detected products, techCategories, fundingRounds, parent and ultimateParent, ticker and a site object with public phone numbers and role addresses.
That is a directory profile page, returned as JSON, for one call. The domain-to-record half of this job is covered in more depth in the firmographics walkthrough.
Step 3. Add the outside view, optional
The endpoints. trustpilot/search_companies, per call, takes query.
What comes back. Reputation rather than firmographics: trust_score, stars, review_count, categories, and a separate row for every domain the brand operates.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to for each company name in this list, find the candidate domains for free, pick the one with the most known email addresses, then pull the full company record and tell me employee count, founded year and detected tech.📖 See also An Email In, a Full Person Profile Out
Which route got the company wrong?
The one built to search by name with relevance scoring, which is the uncomfortable part of this measurement.
What happened
fundable/company/search accepts exactly one of name, domain, linkedin or crunchbase. We gave it name: "Patagonia":
total_count: 2
relevance_score 45 Patagon AI patagon.ai
relevance_score 41 Quantagonia quantagonia.com
Patagon AI is a Latin American sales automation company. Quantagonia is an optimisation software company. Neither is Patagonia, the outdoor clothing company founded in 1973 with 3,780 employees that the free endpoint found in under a second.
Why this happens
A fuzzy matcher scores string similarity against whatever is in its own index. If the index is built around funded technology companies, the closest strings to "Patagonia" inside it are "Patagon AI" and "Quantagonia", and the scorer is working correctly on the wrong population. The scores themselves are honest: 45 and 41 out of 100 are not confident numbers, and a pipeline reading them would know.
What to take from it
Read the score, not the position. A top result with a relevance score of 45 is a guess. The failure here is not that a wrong answer came back; it is that a pipeline ignoring the score would treat it as the answer.
Check the population before the endpoint. A company search is only as good as the set it searches. This is the same lesson as sixty-nine Stripes in the Crunchbase guide: resolution quality is a property of the index, not of the API.
Cross-check on a free endpoint. One free call would have caught this. It returned patagonia.com with 1,320 known addresses while the paid route was scoring 45 on a different company.
And the review index disagreed with itself
trustpilot/search_companies returned twenty companies for the same name. The brand appears twice under two domains with two different reputations: www.patagonia.com at 1.8 with 560 reviews, and eu.patagonia.com at 2.8 with 78. The top row also carries "Travel Agency" among its six categories, which is the region leaking into the brand's own record.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
hunterio/domain-finder | Name to candidate domains | company, limit, perfect_match | Up to 10 domains with email_count | Disambiguating a name first | Free |
hunterio/discover | Structured company search | organization, similar_to, filters | Matching companies with email counts | Filtered discovery, resolves silently | Free |
hunterio/companies/find | Domain to full record | domain | 34 fields: codes, metrics, tech, parent | The directory profile itself | Per call |
fundable/company/search | Fuzzy name search with scoring | Exactly one of name, domain, linkedin, crunchbase | Scored candidates | Lookup by LinkedIn or Crunchbase URL | Per call |
trustpilot/search_companies | Companies on a review index | query | Trust score, stars, review count, categories | The outside view | Per call |
Every row was verified with monid inspect on 2026-09-17. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The first two rows are free, and on this measurement they were also the two that got the company right.
When is a directory the right tool?
Four cases, and they are real ones.
A person is doing the looking. Somebody checking one supplier before a call wants a page with an address and a phone number, not a JSON body. A directory is a good product for that and an API does not replace it.
You need US small business coverage. Directories index small and private companies that enrichment providers built around technology buyers simply do not carry. If your target is a regional contractor, the record may only exist in a directory, and no amount of API choice fixes a missing row.
You want the legal entity, not the company. Registered name, filing status, officers and registered agent come from state registries, not from either of these. That job is the business entity search, and it is a different index again.
The volume is one. Below a few lookups a week, a search box beats writing any integration.
And the disclosure: this is Monid's blog and we resell the five endpoints measured here. The central finding is that the two free ones did the disambiguation better than the paid fuzzy search, which is a recommendation to spend less with us and check the cheap call first.
Conclusion
Searching a company by name looks like one operation and is at least three. On 2026-09-17 a single ordinary name returned ten live companies from a free call, one resolved company from a second free call on the same provider, a thirty-four field record for one paid call, two wrong companies from a paid fuzzy search, and a brand listed twice with two reputations on a review index. None of those routes malfunctioned. They answered different questions that happen to share a search box.
What matters more than the provider is the order. Resolve the name before you buy the record, do it on a free endpoint, and use the size signal that comes back, because email_count spanning 1,320 to 0 sorted ten identical names without a second request. Then read the relevance score on anything fuzzy, because 45 out of 100 is the endpoint telling you it is guessing.
Free next step: run monid run -p hunterio -e /domain-finder on a name you already know the answer to, and count how many companies share it. The call costs nothing and the count is usually higher than you expect. Start at monid.ai.
FAQ
Is there a free alternative to a directory search by name?
For the resolution half, yes, and it was the better half on this measurement. Two endpoints here are free per call: one returns every domain matching a name with a count of known addresses on each, the other runs a structured company search with filters. Between them you can turn a name into the right domain and size it, at no cost and without a record purchase. What stays paid is the record itself, the firmographics, codes, technology and parent company, and that is the correct place for the charge because it is the part with the data in it.
What is the difference between name to domain and name to record?
Name to domain is disambiguation: which of the companies carrying this name do you mean, expressed as a website. Name to record is retrieval: given that you know which one, what is it. They fail differently. Disambiguation fails silently by returning a confident wrong company, which is what happened to the fuzzy search here. Retrieval fails loudly by returning nothing. Always do them in that order, because a perfect record of the wrong company looks exactly like a correct answer downstream.
Why would a company search miss a famous company?
Because it searches its own index, not the world. A matcher built around funded technology companies scored "Patagon AI" at 45 and "Quantagonia" at 41 for the query Patagonia, and never considered the 3,780-person clothing company because that company is not the kind of row it holds. The scores were honest about the uncertainty. The practical rules are to check what population an endpoint indexes before trusting its name search, to read the relevance score rather than the ordering, and to cross-check against a free endpoint that resolves by domain.
Why does one brand have two entries on a review index?
Because review platforms key on the domain a reviewer arrived from, not on the company. The same brand appeared as www.patagonia.com with 560 reviews at 1.8 and as eu.patagonia.com with 78 reviews at 2.8 on the same query. Both are real, they describe different regional operations, and either one on its own would misrepresent the brand. If you are scoring companies on reputation, group by organisation across domain aliases first, and treat a single score attached to a single hostname as one market's view rather than the company's.
Last updated September 2026.
