Target Company URL Analysis: What One Domain Tells You in Four Calls
Start with nothing but a URL. Four calls returned the company, its size, its stack with checkable evidence, and 445 known contacts split by department.
Copy this line to your agent to analyse a company from its URL alone.
set up https://monid.ai/SKILL.md and use firecrawl /scrape then hunterio /companies/find and /email-count
Someone hands you a URL and nothing else. On 2026-09-23 we took one and spent eleven seconds on four calls. Out came the company's own one-sentence positioning, three technologies each with a checkable piece of evidence, a founding year, a headcount, a funding total, and 445 known contacts broken down by department. None of it required knowing the company's name first. This guide runs through Monid, the OpenRouter for agent tools.
What can one company URL actually tell you?
More than the page shows, because a URL is three separate lookups wearing one string.
The page
What the company says about itself, right now, in its own words. Positioning, product names, customers, pricing if they publish it. This is the only source that is authoritative about intent, and the only one that changes the day they change it.
The server
What the site is built on. Headers and HTML patterns reveal hosting, framework, CDN and security posture from a single fetch, with no database involved.
The identity behind it
Who the domain belongs to: legal entity, size, location, funding, and how many people at it you could contact. This comes from indexes, not from the site.
Why the order matters
The page is free of anybody's opinion and instantly current. The identity is the opposite: an index's view, possibly stale, possibly the wrong company. Read them in that order and you notice when the second one disagrees with the first.
📖 See also Best API to Search a Company's Homepage From Its Name
What do four calls return, in order?
Eleven seconds of wall clock for a complete account brief.
Call one, the page
firecrawl/scrape with formats: ["markdown"], 2.5 seconds. Markdown body of 3,218 characters, plus a metadata object:
{ "ogSiteName": "Vercel",
"ogDescription": "The autonomous stack for every app and agent.",
"robots": "index, max-image-preview:large",
"og:url": "https://vercel.com" }
The sentence in ogDescription is the company's own positioning, written by their marketing team, available as one field. The body markdown opens with a skip-nav link and an event banner, which is what homepage body text usually is.
Call two, the server
api.strale.io/x402/tech-stack-detect, 3.2 seconds, three technologies and every one of them showing its working:
Vercel hosting high HTTP header server
Next.js framework high HTTP header x-powered-by
HSTS security high HTTP header strict-transport-security
All three from response headers on one fetch. The same endpoint returned two on our own domain and zero on a large retailer, which tells you what this route is: a reader of one live response, not a database.
Call three, the identity
hunterio/companies/find, 2.5 seconds, 34 fields:
name Vercel
foundedYear 2015
type private
location 94133, San Francisco, California, United States
employeesCount 1011 employees band 1K-5K
trafficRank very_high raised 863,000,000
tech 46 entries
Call four, the people
hunterio/email-count, 1.9 seconds:
total 445 personal 401 generic 44
it 150 sales 53 support 31 hr 18
finance 12 management 11 legal 10 executive 6
What the four together say
A private San Francisco company founded in 2015, roughly a thousand people, 863 million raised, running its own hosting and its own framework, with 445 reachable contacts of whom a third sit in engineering. That is an account brief, from a URL, for four calls.
One caution. A second provider put the same company at 580 employees and reported revenue where this one reports capital raised. Treat any single number as one source's view, which is the whole subject of the lead scoring guide.
How do you analyse a company URL through one key?
Four calls, in the order above, and a fifth only if the URL is wrong.
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. Read the page
monid run -p firecrawl -e /scrape -i '{"url": "https://vercel.com", "formats": ["markdown"]}'
Take data.metadata.ogDescription first and the body second. The metadata is the summary the company wrote; the body is navigation.
Step 2. Read the server
monid run -p api.strale.io -e /x402/tech-stack-detect --query '{"url": "https://vercel.com"}'
Keep the evidence field on every row you store. A technology claim without its evidence is not checkable later.
Step 3. Resolve the identity
monid run -p hunterio -e /companies/find --query '{"domain": "vercel.com"}'
Strip the scheme and any path first. This call wants a bare domain.
Step 4. Map the people
monid run -p hunterio -e /email-count --query '{"domain": "vercel.com"}'
Read the department object, not just the total. The shape of the organisation is in there.
Step 5, only if step 3 came back thin
A URL can be a marketing microsite, a regional subdomain or a redirect target. If the identity call returns little, resolve the brand name back to its primary domain with the free hunterio/domain-finder and try again on that, as measured in the company lookup guide.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to for this URL, get the og description, detect the technologies with their evidence strings, resolve the company record, and give me the contact count by department, then tell me in three sentences what this company is.📖 See also Turn a Domain Into Full Company Firmographics in One Call
Which field is worth more than the page itself?
The Open Graph description, and almost nobody reads it.
Why it beats the body
The body of a homepage is navigation, banners and a hero split across elements. Ours opened with a skip-nav link and a conference promotion. Extracting a company's positioning from that means writing heuristics about which heading is the real one.
ogDescription is one sentence, written by the company, maintained because it is what appears when anyone shares the link. On our subject it read: "The autonomous stack for every app and agent." That is the sentence you would have paid an analyst to write.
What else sits in that metadata
ogSiteName gives you the brand name as the company spells it, which is better than guessing from the domain. robots tells you whether they want the page indexed at all, and a noindex on a company homepage is itself a signal. The canonical URL resolves redirects and regional variants for you.
The second free signal
The generic-to-personal ratio on the address count. Our subject: 44 generic of 445. A domain where most known addresses are info@ and sales@ is a brochure site, a holding company or a business with no online staff footprint, and that is visible before you spend anything on contacts.
And the department shape
150 of 445 contacts in IT is 34 percent, which is a software company. On a clothing retailer the same call put IT at 6 percent and management at 16. You get the character of the organisation from one cheap call, with no technology database involved and no definition of "uses" to argue about.
Which endpoint should I use for which job?
| Endpoint | What it does | Input | Output | Best for | Billing |
|---|---|---|---|---|---|
firecrawl/scrape | Page as markdown plus metadata | url, formats | Body text and og fields | The company's own words | Tiered per call |
api.strale.io/x402/tech-stack-detect | Live technology detection | url | Technologies with evidence strings | Checkable stack claims | Per call |
hunterio/companies/find | Domain to firmographics | domain | 34 fields, headcount, funding, location | The identity | Per call |
hunterio/email-count | Contacts by department | domain | Total, personal, generic, departments | Reachability and org shape | Per call |
hunterio/domain-finder | Brand name to primary domain | company | Candidate domains with counts | When the URL is the wrong one | Free |
Every row was verified with monid inspect on 2026-09-23. The table gives billing shape rather than figures, because shape drives design and current numbers live on monid.ai/tools.
The last row is free and it is the recovery path for the case where all four of the others return thin results.
When does a URL tell you nothing?
Four cases.
The URL is not the company. A campaign microsite, a regional subdomain, a product domain owned by a parent. Every call above will answer about the domain you gave it, correctly and uselessly. Resolve to the primary domain first.
The site is fully client rendered behind a CDN. The live detector returned zero technologies on a large retailer for exactly this reason. That is not a coverage gap, it is what one fetch can see, and the fix is an index rather than a detector.
The company is small and offline. A domain with 53 known addresses of which 29 are generic tells you there is very little online footprint to find. That is a real answer and the right response is to stop spending on it, not to try more providers.
You need the wrong kind of truth. Registered legal entity, officers and filing status come from a registry, not from any of this, and that is the business entity search. Current openings come from job postings. Neither is in a homepage.
And the disclosure: this is Monid's blog and we resell all five endpoints. Two of the most useful outputs here, the positioning sentence and the department mix, come from fields most people ignore inside calls they were already making, which is a way of getting more from fewer requests rather than more requests.
Conclusion
A bare company URL is worth four calls and eleven seconds. Ours produced the company's own positioning sentence as a single metadata field, three technologies each carrying the exact header that proved it, a founding year, a headcount, a funding total, a location, and 445 contacts split across eight departments. That is an account brief assembled from a string somebody pasted into a form.
What matters more than the call count is which fields you read. The Open Graph description beats the page body because it is one maintained sentence rather than navigation. The evidence string on a technology row is the difference between a claim and a checkable fact. And the department split does work that technology databases charge for: a third of known contacts in engineering says software company, and it cost one cheap call to learn.
Free next step: run firecrawl/scrape on a company you know well and read data.metadata.ogDescription before anything else. If it is a better one-line summary than the one in your CRM, that is the finding. Start at monid.ai.
FAQ
Is it better to start from a URL or a company name?
A URL, when you have one, because it is unambiguous and a name is not. A name search on a well-known brand returned ten different companies sharing it in the company lookup guide, and picking the right one is a whole step. A URL skips that step entirely, which is why the chain here is four calls rather than five. The exception is when the URL you were handed is a microsite or a regional subdomain, and then you go backwards: resolve the brand to its primary domain on a free call and restart from there.
What if the URL redirects or is a subdomain?
Read the canonical URL and og:url from the page metadata, which resolve most of this for you without a second request. If they point somewhere other than the URL you started with, use theirs for the identity calls, since the firmographic endpoints key on a bare domain and will happily answer about a subdomain as though it were a company. When the identity call comes back thin for a domain that clearly belongs to a real business, that is usually the signal that you are on a subdomain or a country variant rather than the primary domain.
How should you read the technology evidence strings?
As the only part of a technology claim you can verify. Ours read "HTTP header server", "HTTP header x-powered-by" and "HTTP header strict-transport-security", which means you can curl the site yourself and see the same thing in seconds. Claims with header evidence are strong; claims from HTML content patterns are weaker because markup changes; claims from a database have no evidence at all and should be treated as presence hints. That difference is why the same domain can return three technologies from a live detector and hundreds from an accumulated list, measured in the technographics guide.
Does this work for a list rather than one company?
Yes, with one change of emphasis. For a single account you read everything, including the page body. For a list you drop the page fetch, which is the slowest and least structured call, and run the two identity calls per domain, adding the live detector only where a specific technology decides something. The scoring side of that, including how to handle providers disagreeing by 74 percent on headcount, is the lead scoring guide, which is deliberately a different article from this one.
Last updated September 2026.
