Playbooks · Recipe
Detect a domain's public web technologies with one flat-rate call, drop the accounts that fail the test, and only then spend per-result search credits on finding people. A stack detection is a fit signal, not intent — we sell no intent feed. web_tech_stack bills on any 2xx, including one that finds nothing.
Last updated September 22, 2026
Pattern: domain list → web_tech_stack filter → people search → email finder → email verifier
Credit math: Worked example at stated counts: 500 domains × 1 credit on web_tech_stack = 500 credits, charged on every 2xx including empty detections. 90 domains survive the filter; people_search returns 4 contacts each = 360 results at 0.1 = 36 credits. 360 email_finder calls at 5 = up to 1,800 credits less every miss, which bills zero. 1 credit per web_tech_stack call, 0.1 credits per people_search result, 5 credits per email_finder call
ROI math: The filter is the cheapest call in the chain and it runs first, so 82% of the list is eliminated before any per-result or per-contact spend. Convert credits at your tier rate on /pricing.
Owned internally by: GTM engineer, or a founder doing their own account selection
Best for: Products with a hard technical prerequisite or a named displacement target: integrations, migration tools, analytics, anything that plugs into a specific platform
curl -X POST https://api.richapi.ai/api/v1/web_tech_stack \
-H "x-api-key: $RICHAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://acme.com"}'
Check what web technologies acme.com, globex.com and initech.com are running.
Tell me which of them use Shopify. For those, find two ecommerce or growth
leads per company and get their work emails.
Sign up at app.richapi.ai and copy your key.
25 free credits, no card.
Clean your domain list first — clean_domain strips tracking junk and resolves a messy URL to a root domain, at a fraction of a credit, before you spend a whole one detecting a stack.
Run web_tech_stack per domain and store the full detection, not just your pass/fail verdict. Next quarter's filter will be a different technology.
Filter to the accounts that meet your actual prerequisite.
Be strict — this is the step that saves money.
Run people_search on survivors for the two or three titles that own the technology, then email_finder and email_verifier.
This recipe finds companies that run a particular technology. That is a fit signal. It tells you a prerequisite is met, or that a competitor is installed, and both are good reasons to write to someone. It is not intent. Nobody raised a hand. We do not sell an intent feed, we are [not going to pretend otherwise](/platform), and a page that blurs the two is selling you a story about a `<script>` tag. The tag is real. The buying cycle is a guess. What makes stack data worth paying for is that the guess is cheap to make and easy to check. One flat-rate call per domain tells you whether the account is even eligible, before you spend anything on people. **[Get 25 free credits — no card](https://app.richapi.ai)**
Most teams run this chain backwards. They build the contact list, then wonder which accounts were worth it. The cost lands in exactly the wrong place, because contact data is the expensive end. `web_tech_stack` takes a URL and returns the technologies it can detect on that site. It is a flat per-call charge and it bills on any 2xx — including a response that detects nothing, which is a real outcome on a site built out of one JavaScript bundle. That is not a multi-provider waterfall endpoint and the miss-free rule does not reach it. Budget for the full list, not the survivors. Then, and only then: - `people_search` on the domains that passed, billing per result returned - `email_finder` and `email_verifier` on those people, both waterfall, both zero on a miss
| Step | Count | Rate | Credits | |---|---|---|---| | `web_tech_stack` | 500 domains, all billed | 1 / call | 500 | | `people_search` | 90 survivors × 4 = 360 results | 0.1 / result | 36 | | `email_finder` | 360 calls, 210 hits | 5 / call, misses free | 1,050 | | `email_verifier` | 210 calls | 2 / call | 420 | Rates used above: 1 credit per `web_tech_stack` call, 0.1 credits per `people_search` result, 5 credits per `email_finder` call, 2 credits per `email_verifier` call. Run the same 500 domains without the filter and the finder step alone is roughly five times larger. The filter costs 500 credits and removes 410 accounts before the expensive calls start. Convert to currency at your tier rate on [the pricing page](/pricing), and note that `clean_domain` at half a credit is worth running first on any list that came out of a CRM export full of `?utm_source=` tails.
**Detected is not deployed.** A tag on the marketing site says the marketing team evaluated something. It does not prove the product team runs it, that the contract is current, or that anyone internally likes it. Detection reads public pages; it cannot see the admin panel. **Tag managers hide everything.** A site that loads nearly every third-party script through one tag manager gives up very little at the HTML level. Treat a thin result as unknown, not as absent — writing "I noticed you don't use X" to a company that does is worse than not writing at all. **Stale tags outlive the tool.** Dead scripts sit in templates for years after the subscription lapsed. If your pitch is a displacement pitch, say "it looks like you're running X" and let them correct you. That sentence survives being wrong. "You're running X" does not. **Detection depends on what the page exposes.** Some stacks are simply not visible from outside. An empty result is a limit of the method, and we would rather write that down than sell you a coverage claim.
Filtering on what a company *runs* pairs naturally with filtering on what it is *doing*: see [hiring signals to outbound](/use-cases/hiring-signal-to-outbound) for the staffing version, or [the use-case index](/use-cases) for the rest. To score the survivors rather than pass/fail them, [ICP filter with AI enrich](/use-cases/icp-filter-with-ai-enrich) runs an LLM over the enriched record. The endpoint itself is documented at [the tech stack lookup API](/api/tech-stack-lookup), and [people search](/api/people-search) covers the contact step.
**Is this intent data?** No. It is technographic fit. We have no intent product, and a detected technology is not a signal that anyone is shopping. **Does a call with no detections still cost me?** Yes. `web_tech_stack` bills on any 2xx, empty included. Only the waterfall endpoints — `email_finder`, `email_verifier`, `phone_finder` — return `billed: false` on a miss. A non-2xx never bills, on any endpoint. **How current is the detection?** It is fetched when you call. There is no cached technographic index behind this and we are not selling you index size, so re-run the filter when it matters rather than trusting a result from six months ago. **Can I filter on the absence of a technology?** Carefully. Absence in the response means "not detected," which is not the same as "not used," for all the reasons above. Build the pitch so being wrong is survivable. **Can I call this from Claude or Cursor (MCP)?** Yes. `web_tech_stack` is exposed as a tool on [the hosted MCP server](/integrations/claude), so you can qualify a handful of domains conversationally before you commit to scripting the batch. **Do I need a credit card?** No. 25 free credits on signup.
Point it at ten domains you already know well and check whether the detections match reality. **[Get 25 free credits](https://app.richapi.ai)**