Playbooks / Recipe
Pixels first, stack second: a two-call qualification pass
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.
Pattern: domain list → clean_domain → web_pixels → web_tech_stack on survivors → contact spend
In short: A RichAPI recipe for qualifying domains by detected pixels before spending on contact data. POST https://api.richapi.ai/api/v1/web_pixels returns tracking and advertising pixels detected on a public page at a flat credits_per_call rate. POST /web_tech_stack returns the wider detected technology stack, also flat rate. Both endpoints bill on any 2xx response, including a response where nothing is detected; they are not waterfall endpoints and the zero-cost-miss rule does not apply to them. Only non-2xx responses are unbilled. Detection is limited to what a public page exposes, so an empty result means the technology was not observable, not that it is unused. POST /clean_domain normalises URLs to root domains at a fractional rate before detection. Authentication uses the x-api-key header. New accounts get 100 free credits and require no credit card.
Last updated November 4, 2026
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
- 01
Sign up at app.richapi.ai and copy your key.
100 free credits, no card.
- 02
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.
- 03
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.
- 04
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.
- 05
Record an empty detection as unknown in your own schema.
Do not let it become a negative claim in a sequence.
- 06
Send the survivors to people_search, email_finder and email_verifier.
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.
A pixel is a budget line
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.
Detection sees a public page, nothing more
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.
Both calls bill on empty
Neither of these is a waterfall endpoints 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.
What pixel detection costs, at stated counts
| 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.
Where pixel detection goes wrong
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.
Plays related to pixel detection
The stack-only version of this filter is 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 and Meta ads to an account list. Traffic as a filter is covered in SimilarWeb traffic qualify. Endpoint reference lives at the tech stack lookup API, the platform overview explains where the data layer stops, and the use-case index has the rest.
Pixel detection FAQ
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. 100 free credits on signup.
Try pixel detection: 100 free credits, no card
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 100 free credits
FAQ