Playbooks · Recipe
One call tells you which tracking and advertising pixels a site loads; another tells you what else it runs. Two flat-rate calls per domain, both billed on any 2xx including one that detects nothing. Detection sees what a public page exposes and no more — an empty result means the page did not show it, not that the company does not use it.
Last updated September 22, 2026
Pattern: domain list → clean_domain → web_pixels → web_tech_stack on survivors → contact spend
Credit math: Worked example at stated counts: 600 messy URLs through clean_domain at 0.5 = 300 credits. 600 web_pixels calls at 1 credit = 600, every one billed including the 140 that detect nothing. 180 domains carry an ad pixel and go to web_tech_stack at 1 credit = 180. Total qualification spend 1,080 credits before a single contact lookup. 0.5 credits per clean_domain call, 1 credit per web_pixels call, 1 credit per web_tech_stack call
ROI math: Both detection calls are flat-rate and cheap relative to contact data, and they run before the per-result and per-call contact spend. Qualifying 600 domains for 1,080 credits to avoid running email_finder on 420 of them is the entire argument. Convert credits at your tier rate on /pricing.
Owned internally by: Demand-gen or GTM engineer doing account selection
Best for: Anyone selling to companies that run paid acquisition — agencies, ad tools, CRO, attribution, analytics, anything downstream of a marketing budget
curl -X POST https://api.richapi.ai/api/v1/web_pixels \
-H "x-api-key: $RICHAPI_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://acme.com"}'
For acme.com, globex.com and initech.com: check which advertising and
analytics pixels each site loads. For any site carrying a Meta or Google Ads
pixel, also pull its full technology stack. Summarise as a table and tell me
which of the three is most likely to be spending on paid acquisition.
Sign up at app.richapi.ai and copy your key.
25 free credits, no card.
Run clean_domain over the list first.
A CRM export full of utm tails and redirect wrappers will otherwise burn full-price detection calls on the same root domain three times.
Call web_pixels per domain.
Store the complete detection, not your pass/fail verdict — the pixel that qualifies an account next quarter is not the one that qualifies it today.
Take only the domains carrying a pixel you care about and call web_tech_stack on those.
Running both calls on every domain doubles the bill for no extra decision.
Record an empty detection as unknown in your own schema.
Do not let it become a negative claim in a sequence.
Send the survivors to people_search, email_finder and email_verifier.
A Meta pixel on a homepage means somebody, at some point, wired that site to a paid acquisition account. Compared with firmographics — headcount bands, industry codes, a funding round from 2023 — that is a much more direct read on whether the company spends money on the thing you sell. Two calls get you there. `web_pixels` returns the tracking and advertising pixels a page loads. `web_tech_stack` returns the broader technology picture. Both are flat per-call, both run before you touch contact data. **[Get 25 free credits — no card](https://app.richapi.ai)**
Say this out loud before you build anything on top of it: these endpoints fetch a page and report what the page exposed. That is the whole method. So an empty result has three possible meanings, and the API cannot tell you which one you got: - The company does not use that technology. - The company uses it, but loads it through a tag manager or a server-side container that never reveals the underlying tool in the HTML. - The page you asked for is not the page that carries the tag: a bare root domain that redirects to a regional site, or a marketing homepage sitting in front of an app that runs everything else. Treat a thin result as **unknown**. The teams that get burned here are the ones who write "I noticed you're not running any attribution" to a company running a full server-side setup. Being wrong in an opening line is not a rounding error; it is the whole email.
Neither of these is a multi-provider waterfall endpoint. `email_finder`, `email_verifier` and `phone_finder` are the endpoints where a soft fail returns `success: false` with `billed: false` and costs you nothing. `web_pixels` and `web_tech_stack` are not in that set — a 2xx bills, even when the detection array comes back with nothing in it. A non-2xx never bills, on any endpoint. Budget for the whole list, not for the hits. That is why the sequencing matters: run the cheap flat calls across everything, then run the expensive contact calls across the survivors only.
| Step | Count | Rate | Credits | |---|---|---|---| | `clean_domain` | 600 URLs | 0.5 / call | 300 | | `web_pixels` | 600 domains, all billed | 1 / call | 600 | | `web_tech_stack` | 180 pixel-carrying domains | 1 / call | 180 | | Qualification subtotal | | | **1,080** | Rates used above: 0.5 credits per `clean_domain` call, 1 credit per `web_pixels` call, 1 credit per `web_tech_stack` call. Now compare that to the alternative. Running `people_search` and `email_finder` across all 600 domains instead of 180 is roughly three times the contact bill, and contact data is the expensive end of every chain we publish. Convert to currency at your tier rate on [the pricing page](/pricing).
**Server-side tagging erases the evidence.** The better a company's measurement setup, the less of it you can see from outside. Sophisticated advertisers are exactly the accounts most likely to return a thin pixel result, which inverts the signal if you score on count. **Pixels rot in templates.** A pixel for a tool the company stopped paying for in 2024 is still a pixel. If your pitch depends on current usage, phrase it as an observation — "it looks like your site still loads X" — so their correction becomes a reply rather than an unsubscribe. **Subdomains and regional splits.** `acme.com`, `www.acme.com`, `shop.acme.com` and `acme.de` can return four different stacks. `clean_domain` normalises the junk; it does not decide which property is the one you meant. That judgment stays with you. **Two calls where one would do.** If your qualification only needs the pixel, stop after `web_pixels`. Running the stack call on every domain out of completeness doubles your flat-rate spend and changes no decision you were going to make.
The stack-only version of this filter is [tech stack intent outbound](/use-cases/tech-stack-intent-outbound), which also explains why technographics are fit and not intent, since we sell no intent feed. For ad-spend evidence from the ad platforms themselves rather than from the site, see [Google Ads transparency to outbound](/use-cases/google-ads-transparency-to-outbound) and [Meta ads to an account list](/use-cases/meta-ads-to-account-list). Traffic as a filter is covered in [SimilarWeb traffic qualify](/use-cases/similarweb-traffic-qualify). Endpoint reference lives at [the tech stack lookup API](/api/tech-stack-lookup), [the platform overview](/platform) explains where the data layer stops, and [the use-case index](/use-cases) has the rest.
**What is the difference between web_pixels and web_tech_stack?** `web_pixels` is narrow and aimed at tracking and advertising tags. `web_tech_stack` is the broad detection pass. Run the narrow one first because it answers the qualification question with one call. **Does an empty detection cost credits?** Yes. Both endpoints bill on any 2xx, empty included. Only `email_finder`, `email_verifier` and `phone_finder` return `billed: false` on a miss. **Can I trust this to prove a company is running ads?** It proves the page loads a pixel. Campaign existence, spend level and recency are not in the response. If you need running-creative evidence, the ad library plays above are the better source. **Is the result cached?** It is fetched when you call. There is no stored technographic index behind this, which is the same reason we do not quote an index size anywhere on this site. **Should I store the full response or my verdict?** The full response. Verdicts are cheap to recompute and impossible to recover. **Do I need a credit card?** No. 25 free credits on signup.
Point it at five domains whose marketing stack you already know and see how much of it comes back. The gap between what you know and what the page exposes is the number worth having. **[Get 25 free credits](https://app.richapi.ai)**