# Company Enrichment API - Domain to Firmographics, Tech & Email (`santhej/company-intel-lookup`) Actor One domain in, one flat JSON company profile out: company name, address, emails, phones, socials, full tech stack, the back-office SaaS a company runs read from DNS, and a graded MX/SPF/DMARC/DKIM deliverability verdict. Flat price per domain, no run minimum, no free-tier penalty. Built for agents. - **URL**: https://apify.com/santhej/company-intel-lookup.md - **Developed by:** [Santhej Kallada](https://apify.com/santhej) (community) - **Categories:** Automation - **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks - **User rating**: 5.00 out of 5 stars ## Pricing from $8.00 / 1,000 company enricheds This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event ## What's an Apify Actor? Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows. In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours, and optionally produces a well-defined JSON output, datasets with results, or files in key-value store. In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server. Actors are written with capital "A". ## How to integrate an Actor? If asked about integration, you help developers integrate Actors into their projects. You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready. The best way to integrate Actors is as follows. - **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use). - **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`. - **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`. - **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`. - **Any other language** — the [REST API](https://docs.apify.com/api/v2.md). For usage examples, see the [API](#api) section below. For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt). # README ## Company Enrichment API — Domain to Firmographics, Tech & Email **Give it a domain. Get one flat JSON company profile back: company name and address, emails, phones, social profiles, the full tech stack, the back-office SaaS the company runs read straight from its DNS, and a graded MX / SPF / DMARC / DKIM deliverability verdict.** No other actor returns all six of those in one call. Today you stitch that together from a firmographics actor, a contact scraper, a tech-stack detector and a DNS/email checker — four calls, four schemas, four failure modes, four bills. This is one call, one flat row, one price. - **One required field.** `{"domains":["stripe.com"]}` is a complete, correct call. - **The key you already have.** A domain — not a LinkedIn company URL, not a company name you have to resolve first. - **Flat price per domain, no run minimum.** $0.008 per company enriched. A one-domain lookup costs $0.00805, not a $0.50 run floor. - **Same price on every plan tier.** Free-tier gouging is standard in this category; there is none here. - **No API keys, no vendor accounts, no proxy setup.** Every signal comes from the company's own DNS, its own website, and public unauthenticated job boards. - **Deterministic.** No LLM in the path. Same domain, same day, same JSON. *** ### What you get per domain #### Firmographics Company name (with a `company_name_source` so you can weight how it was derived), legal entity name, description, logo, country, street address, city, region, postal code, VAT ID, founded year, primary language. #### Contacts and socials Role email addresses on the company's own domain, phone numbers, and up to eight social profiles — LinkedIn, X/Twitter, Facebook, Instagram, YouTube, **GitHub** (a strong developer-tooling buying signal), TikTok and Crunchbase. #### Tech stack A deduplicated technology list with categories, plus first-class verdicts for `cms`, `ecommerce_platform`, `analytics`, `cdn`, `web_server` and `is_wordpress`. Fingerprints are matched only against tags and script bodies, never visible page text — so a marketing page that *mentions* a competitor's product does not get tagged as running it. Fingerprint definitions come from the open-source **Wappalyzer** technology dataset (v6.10.54), used under the **MIT licence**; the licence text and notice ship inside the actor image. The matching engine, the code-surface restriction that kills the false positives, and the category verdicts above are this actor's own. #### Back-office SaaS from DNS — the signal a tech-stack scanner structurally cannot see Website fingerprinting only ever observes the marketing site's frontend. Domain-verification records in DNS expose what the company **bought** for its back office: Microsoft 365, Atlassian, Slack, Zoom, Docusign, Miro, Adobe. Those land in `paid_saas_vendors`. Free-product tokens (Search Console, Meta Business, Canva, Apple) are kept separate in `free_verification_tokens` — calling a free tool a purchase would inflate the number, so we don't. #### Graded email infrastructure, not raw records Most actors dump raw DNS strings, or return `has_spf: true` and stop. This returns the **interpreted verdict**: the mail provider derived from MX, SPF strictness (`-all` hard fail vs `~all` soft fail vs the `+all` misconfiguration), the DMARC **policy** (`none` / `quarantine` / `reject`), DKIM via provider-aware selector probing, BIMI, and a deterministic **A–F `email_security_grade`** from a published rubric — one field to filter a list on. The grade is `null` in exactly one situation: a DNS lookup failed, so the evidence was never obtainable. A resolver timeout and a domain that publishes no SPF at all produce the same empty answer, and a grade of `F` on the first would be a confident, false claim about a real company's security posture. When the records were read, the grade is a letter; when they could not be read, it is `null` and the caps that would have punished the "missing" records are suppressed. `null` means *we could not establish this*, never *unprotected*. `email_marketing_tools` decodes the SPF chain into the martech the company actually sends through: HubSpot, SendGrid, Klaviyo, Marketo, Mailchimp, Zendesk, Salesforce, Postmark, Amazon SES, Brevo, Intercom, Customer.io. #### Company size — a band, with a confidence `company_size_signal` is `smb` / `mid_market` / `growth` / `enterprise`, and it is **null when the evidence cannot narrow the range** — an unknown band beats a wrong one. A verified open-role count decides the band on its own, as a floor on implied headcount; DNS-visible SaaS vendor counts and sitemap size are only precise enough to name the bottom band, never a middle one. `company_size_confidence` is `high` only when the role count is not sitting near a band threshold. *** ### What this actor does **not** return, and why **No `employee_count`. No `revenue`. No `funding`. No `industry_code`.** Companies do not publish headcount in machine-readable markup — it appeared in **0 of 14** sampled sites carrying structured company data. Every product that shows you a precise employee number for an arbitrary domain either bought it from a data broker or guessed. Guessing is how this category generates refund requests, so we ship a band and a confidence instead of a fabricated number. If you need firmographic headcount and revenue, pair this with a LinkedIn company actor. This one tells you the truth about what it can see. *** ### Hiring signals — read this before you rely on them Hiring is shipped, and it is genuinely useful when it lands. It is **not** a headline feature, and the numbers are why. The actor identifies the applicant tracking system a company uses and, when you enable `include_open_roles`, returns the open-role count, the departments hiring and a ten-role sample. **On a mixed 30-domain list of the kind a real buyer uploads — local services, DTC brands, mid-market SaaS, ecommerce — a job board was found for about 30% of domains. After the verification guard runs, usable hiring data lands on roughly 13%.** The rate is much higher on tech and DTC companies and near zero on local service businesses. The verification guard is the reason for that gap, and it is deliberate. Job-board identifiers are guessable, and a guess can land on a completely unrelated company's board — we hit exactly that live, where one company's identifier returned a board belonging to an unrelated business with a similar name. So: - `ats_verified` is `true` only when the board was positively tied to **this** company. - `ats_source` tells you exactly how: an on-page marker, the mail-sending chain, a board name match, or a job link on the company's own domain. `slug_guess_unverified` means we found a board and could **not** confirm it is theirs. - When `ats_verified` is `false`, **`open_roles_count` and `is_hiring` are `null`**, not a number from someone else's board. A null you can trust beats a number you can't. `include_open_roles` defaults to `false` for that reason, and because it removes the largest download from the request path. > Fill rates quoted in this README were measured on samples of tens of domains, not thousands. Treat them as honest order-of-magnitude guidance, not guarantees. *** ### Pricing | Outcome | `status` | Charged | |---|---|---| | Website **and** DNS both delivered | `ok` | **$0.008** — `company-enriched` | | Website blocked or broken, DNS layer delivered | `partial_dns_only` | **$0.004** — half price | | Domain does not resolve | `unreachable` | **Free** | | Input could not be parsed as a domain | `invalid_input` | **Free** | | Blocked site rescued via the opt-in residential retry | — | **+$0.02**, only when the retry returns usable HTML | | Run start | — | $0.00005 once per run | **Why blocked domains still cost something, and why it is half.** When a website blocks us, DNS still answers — in probing, DNS returned answers for **every** domain tested, including all three that hard-blocked their website. You still get the mail provider, SPF policy, DMARC policy, DKIM, BIMI, the graded verdict and the paid-SaaS vendor list. That is still the most complete result available for a blocked domain. But there are no emails, no socials, no tech stack and only a domain-derived company name — so full price would be opportunistic. Half price is the honest answer. **No run minimum. No start-fee trap. No free-tier surcharge.** Your cost is knowable before you call: `len(domains) × $0.008 + $0.00005`, worst case. Blocked domains cost less. Junk domains cost nothing. Duplicates and subdomains that collapse to the same apex are deduplicated before anything is fetched, so passing `stripe.com`, `www.stripe.com` and `https://stripe.com/pricing` bills once. *** ### Example input Minimum viable call: ```json { "domains": ["stripe.com"] } ``` Everything turned up: ```json { "domains": ["stripe.com", "www.notion.so", "https://sennheiser.de/about"], "verbosity": "full", "max_pages": 4, "include_tech_stack": true, "include_open_roles": true, "role_emails_only": true, "residential_fallback": true, "max_concurrency": 8 } ``` ### Example output One row per domain, every key present on every row — `null` where not applicable, `[]` (never `null`) for arrays. Index `record["dmarc_policy"]` without a defensive check. ```json { "domain": "stripe.com", "status": "ok", "error": null, "final_url": "https://stripe.com/", "fetched_at": "2026-08-14T09:21:44.118Z", "company_name": "Stripe", "company_name_source": "json_ld", "legal_name": "Stripe, Inc.", "description": "Stripe is a suite of APIs powering online payment processing and commerce solutions for internet businesses of all sizes.", "logo_url": "https://images.stripeassets.com/fzn2n1nzq965/HTTOloNPhisV9P4hlMPNA/cacf1bb88b9fc492dfad34378d844280/Stripe_icon_-_square.svg", "country_code": "US", "street_address": "354 Oyster Point Boulevard", "city": "South San Francisco", "region": "CA", "postal_code": "94080", "vat_id": null, "emails": ["press@stripe.com", "support@stripe.com"], "phones": ["+1 888-926-2289"], "linkedin_url": "https://www.linkedin.com/company/stripe", "twitter_url": "https://twitter.com/stripe", "facebook_url": null, "instagram_url": null, "youtube_url": "https://www.youtube.com/stripe", "github_url": "https://github.com/stripe", "tiktok_url": null, "crunchbase_url": null, "social_profile_count": 4, "ats_vendor": "Greenhouse", "ats_verified": true, "ats_source": "spf_include", "open_roles_count": null, "is_hiring": null, "hiring_departments": [], "technologies": ["Cloudflare", "Contentful", "HSTS", "Next.js", "React", "Segment", "Stripe.js"], "technology_count": 7, "tech_categories": ["CDN", "CMS", "JavaScript Frameworks", "Payment Processor", "Analytics", "Security"], "cms": "Contentful", "ecommerce_platform": null, "analytics": ["Segment"], "cdn": "Cloudflare", "web_server": null, "is_wordpress": false, "paid_saas_vendors": ["Atlassian", "Docusign", "Microsoft 365", "Slack"], "saas_vendor_count": 4, "mx_provider": "Google Workspace", "spf_present": true, "spf_policy": "-all", "email_marketing_tools": ["Salesforce", "SendGrid"], "dmarc_present": true, "dmarc_policy": "reject", "dkim_present": true, "bimi_present": false, "email_security_grade": "A", "company_size_signal": "enterprise", "company_size_confidence": "high", "has_blog": true, "has_pricing_page": true, "has_security_page": true, "used_residential": false, "signals_found": 4, "data_completeness": 0.81 } ``` A domain whose website blocks us still returns the full DNS layer (abbreviated below — the row still carries all 61 core keys, the website-derived ones empty): ```json { "domain": "example-blocked.com", "status": "partial_dns_only", "error": "HTTP_BLOCKED", "company_name": "Example Blocked", "company_name_source": "domain_root", "emails": [], "technologies": [], "mx_provider": "Microsoft 365", "spf_present": true, "spf_policy": "~all", "dmarc_present": true, "dmarc_policy": "quarantine", "dkim_present": true, "bimi_present": false, "email_security_grade": "C", "paid_saas_vendors": ["Microsoft 365", "Zoom"], "signals_found": 2, "data_completeness": 0.44 } ``` *** ### Core vs full fields `verbosity` defaults to `"core"` (**61 fields**). Core drops the raw records that duplicate a verdict already interpreted for you — there is no point handing an agent both `spf_policy: "-all"` and the raw SPF string. Set `"verbosity": "full"` for all **85 fields** when a human is reading the output or you want the raw evidence. **Core (61) — returned by default** | Group | Fields | |---|---| | Identity & status | `domain`, `status`, `error`, `final_url`, `fetched_at` | | Firmographics | `company_name`, `company_name_source`, `legal_name`, `description`, `logo_url`, `country_code`, `street_address`, `city`, `region`, `postal_code`, `vat_id` | | Contacts & socials | `emails`, `phones`, `linkedin_url`, `twitter_url`, `facebook_url`, `instagram_url`, `youtube_url`, `github_url`, `tiktok_url`, `crunchbase_url`, `social_profile_count` | | Hiring | `ats_vendor`, `ats_verified`, `ats_source`, `open_roles_count`, `is_hiring`, `hiring_departments` | | Tech stack | `technologies`, `technology_count`, `tech_categories`, `cms`, `ecommerce_platform`, `analytics`, `cdn`, `web_server`, `is_wordpress` | | SaaS from DNS | `paid_saas_vendors`, `saas_vendor_count` | | Email infrastructure | `mx_provider`, `spf_present`, `spf_policy`, `email_marketing_tools`, `dmarc_present`, `dmarc_policy`, `dkim_present`, `bimi_present`, `email_security_grade` | | Signals | `company_size_signal`, `company_size_confidence`, `has_blog`, `has_pricing_page`, `has_security_page`, `used_residential`, `signals_found`, `data_completeness` | **Full adds 24 more** | Group | Fields | |---|---| | Identity & status | `http_status`, `input_value` | | Firmographics | `founded_year`, `primary_language`, `latitude`, `longitude` | | Contacts | `contact_page_url`, `about_page_url` | | Hiring | `ats_board_url`, `open_roles_sample`, `open_roles_truncated` | | Tech stack | `tech_scan_complete`, `free_verification_tokens` | | Email infrastructure | `mx_hosts`, `spf_record`, `spf_includes`, `dmarc_pct`, `dmarc_rua`, `dkim_selectors_found` | | Diagnostics | `security_txt_present`, `sitemap_url_count`, `page_title`, `canonical_url`, `pages_fetched` | `open_roles_sample` is the only nested structure in the record — up to ten `{title, department, location, is_remote, url}` objects — which is exactly why it is full-only and the rest of the record stays strictly flat. *** ### Judging a row without a second call Four fields answer "should I trust this?": - **`status`** — four values, the top-level branch: `ok`, `partial_dns_only`, `unreachable`, `invalid_input`. - **`data_completeness`** — 0–1, scored against the fields that were **attainable** for that row given its status and your input flags, so a perfectly good record does not score 0.3 just because the company has no street address in its markup. - **`signals_found`** — 0–5: company, contacts + socials, tech stack, DNS/email, hiring. - **`ats_verified` + `ats_source`** — exactly how the hiring claim was derived, or that it wasn't. `error` carries the machine code when something went wrong: `INVALID_DOMAIN`, `DNS_NXDOMAIN`, `HTTP_BLOCKED`, `HTTP_ERROR`, `TIMEOUT`, `TLS_ERROR`, `EMPTY_SHELL`. *** ### Built for agents and pipelines - One required input, eight total. Nothing to configure to get a correct call. - Flat output — no nesting to traverse at core verbosity, so an LLM reads it straight. - Cost is computable before the call, which matters when an agent is under a budget. - Failures degrade instead of throwing: a blocked website still returns the DNS layer, a dead domain returns a clean `unreachable` row and costs nothing. - Works from n8n, Make, Zapier, MCP tool calls, or the Apify API directly. Typical uses: enriching a raw domain list into a CRM, qualifying inbound signups from their email domain, deliverability and email-security prospecting, tech-stack-based targeting, and giving a sales agent everything it needs about an account in one tool call. *** ### Data use, GDPR and responsible outreach Read this before you feed the output into cold outreach. **What we collect and don't.** - Email addresses are returned **only** from the company's own domain. Addresses on any other domain are dropped unconditionally — this is not a toggle. Measured on a single site, `/about` and `/privacy` pages leaked 13 unrelated third-party addresses; those never reach your output. - `role_emails_only` defaults to **on**, restricting output to generic role accounts (`info@`, `sales@`, `support@`, and similar) rather than named individuals. - Team, staff, people and leadership pages are **never crawled**. They are the highest-yield source of named natural persons, and we do not go there. - For `.de` / `.at` / `.ch` domains the statutory Impressum is read for legal entity name, address and VAT ID **only**. The managing director's name is deliberately not extracted, even though the page publishes it by law. - Only publicly published, unauthenticated pages are read. Nothing is logged into, no paywall is bypassed, and no personal data is purchased from a broker. **Your obligations.** Data returned here is business contact information, but you are the controller once you use it. Under **GDPR** you need a lawful basis and must honour access and erasure requests. Germany's **UWG §7** makes unsolicited commercial email to businesses unlawful without prior consent — unlike the US CAN-SPAM regime, opt-out is not enough there, and several other EU jurisdictions are similarly strict. Check the rules for the recipient's country, not yours. Turning `role_emails_only` off is available for legitimate uses such as security research and deliverability auditing; if you turn it off for cold outreach, that is your call and your liability. We do not resell, retain or index anything this actor fetches. Output lives in your own dataset. *** ### FAQ **What do I pass in?** A domain. `stripe.com`, `www.stripe.com`, `https://stripe.com/pricing` and `hello@stripe.com`-style hosts all normalise to the same apex. **Do I need proxies or API keys?** No. Both are optional-to-nonexistent: there are no vendor credentials anywhere, and residential proxy use is a single opt-in retry for blocked sites. **How fast is it?** Roughly 15–17 minutes per 1,000 domains at the default memory allocation, where the container gets a quarter of a CPU core. A single-domain call returns in a few seconds. Turning off `include_tech_stack` is the biggest latency lever. **Why is a field null?** Because the company does not publish it. The cascade for `company_name` bottoms out at the domain root, so that one is effectively always filled; address, VAT ID, founded year and coordinates depend on structured markup most sites do not carry. One field is null for a different reason: `email_security_grade` is `null` when a DNS lookup failed, because a grade computed on records we could not read would be a guess dressed as a finding. **Can I get more than 5,000 domains?** Split them across runs. Per-run cap is 5,000. **Is the output stable?** Yes — no model in the path, and the key set never changes for a given `verbosity`. *** *Tags: company enrichment, domain enrichment, firmographics, B2B data, lead enrichment, tech stack detection, technology lookup, email verification, SPF DMARC DKIM, deliverability, MX lookup, sales intelligence, prospecting, AI agents, MCP.* # Actor input Schema ## `domains` (type: `array`): Company domains to enrich, one per line. Accepts a bare apex ('stripe.com'), a 'www.' host, a full URL ('https://stripe.com/pricing') or an email-style host — everything is normalised to the apex domain first. Duplicates and subdomains that collapse to the same apex are deduplicated, so you are never charged twice for the same company. Up to 5,000 per run. ## `verbosity` (type: `string`): How many fields each row carries. 'Core' drops raw-record duplicates of already-interpreted verdicts (raw SPF/MX/DMARC strings, page title, canonical URL, geo coordinates and the diagnostic block) — the right default when an LLM agent reads the output, because a 50-domain call at full verbosity is thousands of key/value pairs of context. 'Full' returns every field. ## `max_pages` (type: `integer`): Hard ceiling on HTML pages fetched per domain; the homepage counts as 1. The default of 4 buys homepage + the best contact link + the best legal/privacy link + the best careers link (on .de/.at/.ch the statutory Impressum takes the fourth slot instead). Deeper crawling adds no new fields and pollutes the contact data. Does NOT change the price: billing is per domain, never per page. ## `include_tech_stack` (type: `boolean`): Run the fingerprint matcher for technologies, CMS, ecommerce platform, analytics and CDN. This is the only CPU-heavy step; turn it off for the lowest-latency single-domain agent call. Every other signal family still returns, and the price is unchanged either way. ## `include_open_roles` (type: `boolean`): When off, the actor still identifies the applicant tracking system the company uses, but skips every job-board payload — which removes the largest single download from the hot path. Turn it on to also return the open-role count, the departments hiring and a 10-role sample. See the README for the honest hit rate before relying on this. ## `role_emails_only` (type: `boolean`): GDPR-conservative default. When on, only role accounts on the company's own domain are returned (info@, hello@, sales@, support@, contact@, press@, careers@, hi@, team@, enquiries@, admin@, office@). Addresses on other domains are ALWAYS dropped regardless of this setting, and team/staff pages are never crawled. ## `residential_fallback` (type: `boolean`): Opt-in single retry through a residential IP when a site answers 403, 429 or 451. Hard-capped at one request and 150 KB of wire traffic. Billed as a separate 'Blocked site unblocked' event only when the retry actually returns usable HTML — never on a failed attempt. If your account has no residential proxy access the run logs a warning and continues normally. ## `max_concurrency` (type: `integer`): How many domains are enriched in parallel. The default of 8 is tuned for the actor's 1 GB memory allocation, where the container gets a quarter of a CPU core and higher concurrency makes request timeouts fire late and spuriously. Per-host concurrency is always pinned to 1 regardless of this value. ## Actor input object example ```json { "domains": [ "stripe.com" ], "verbosity": "core", "max_pages": 4, "include_tech_stack": true, "include_open_roles": false, "role_emails_only": true, "residential_fallback": false, "max_concurrency": 8 } ``` # Actor output Schema ## `dataset` (type: `string`): One row per domain: firmographics, contacts, socials, tech stack, DNS-derived SaaS and the graded email deliverability verdict. ## `summary` (type: `string`): Counts by status, mean completeness, fill rate per signal family and charged events by type. # API You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup. ## JavaScript example ```javascript import { ApifyClient } from 'apify-client'; // Initialize the ApifyClient with your Apify API token // Replace the '' with your token const client = new ApifyClient({ token: '', }); // Prepare Actor input const input = { "domains": [ "stripe.com" ] }; // Run the Actor and wait for it to finish const run = await client.actor("santhej/company-intel-lookup").call(input); // Fetch and print Actor results from the run's dataset (if any) console.log('Results from dataset'); console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`); const { items } = await client.dataset(run.defaultDatasetId).listItems(); items.forEach((item) => { console.dir(item); }); // 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs ``` ## Python example ```python from apify_client import ApifyClient # Initialize the ApifyClient with your Apify API token # Replace '' with your token. client = ApifyClient("") # Prepare the Actor input run_input = { "domains": ["stripe.com"] } # Run the Actor and wait for it to finish run = client.actor("santhej/company-intel-lookup").call(run_input=run_input) # Fetch and print Actor results from the run's dataset (if there are any) print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}") for item in client.dataset(run.default_dataset_id).iterate_items(): print(item) # 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start ``` ## CLI example ```bash echo '{ "domains": [ "stripe.com" ] }' | apify call santhej/company-intel-lookup --silent --output-dataset ``` ## MCP server setup ```json { "mcpServers": { "apify": { "type": "http", "url": "https://mcp.apify.com/?tools=fetch-actor-details,santhej/company-intel-lookup" } } } ``` The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer ` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations). ## OpenAPI specification Download the OpenAPI definition: https://api.apify.com/v2/actors/Xy3CECGYstk0Z2ffO/builds/ZXUGYeSJY7TV14Y9o/openapi.json