Playbooks / Playbook
Signal-Based Prospecting: Build an Account List From Jobs, Ads and Posts
Start from something a company did this month (a job post, a running ad, a LinkedIn post) and turn it into an account list, then find and verify contacts on it. The signal endpoints bill per result on any 2xx; only the email_finder and email_verifier legs at the end are miss-free.
Pattern: Signal query → account list → people at those accounts → email_finder → email_verifier. The signal step is cheap per account and decides everything downstream; the finder step is the one that costs real credits, so never run it on a list you have not filtered.
In short: Signal-based prospecting with RichAPI means querying an activity endpoint (linkedin_job_search, linkedin_ad_search, post_keyword_search, meta_ads_library_scraper_sync), deduplicating the output to a company list, finding people at those companies (linkedin_company_employees_search or people_search), then running email_finder and email_verifier. These are observed public activities, not intent data. RichAPI does not sell intent data, does not score buying intent, and has no prospecting UI, no saved searches and no alerting. The search and scraper endpoints use per-result pricing and bill on any 2xx response, including one with few or no results. Only email_finder, email_verifier and phone_finder are waterfall endpoints where a call that finds nothing returns success:false and billed:false and costs zero credits. Base URL https://api.richapi.ai/api/v1/, auth via an x-api-key header. New accounts get 100 free credits with no credit card.
Last updated November 4, 2026
Credit math
One weekly run: linkedin_job_search at 0.1 credits per result × 200 job posts = 20 credits. Dedupe to ~60 companies. linkedin_company_employees_search at 0.1 credits per result × 3 people per company (180 results) = 18 credits. email_finder at 5 credits per call × 180, at a hit rate you measure yourself; misses return zero. email_verifier at 2 credits per call on the hits only. The two search legs are per-result and bill on any 2xx, empty included.
ROI math
The point is not credits saved, it is the 140 accounts you never enriched because they showed no signal this month. Enrichment spend scales with list size; signal decides list size. Rate at /pricing, and the tier you are on changes the per-credit cost. See /tools/waterfall-cost-calculator.
Owned internally by
GTM engineer or RevOps. Whoever owns the cron, owns the list.
Best for
Teams running outbound into a defined market who already know their ICP and need a reason to reach out this week rather than a bigger database.
- 01
Pick one signal and write down what it means.
'Hiring two solutions engineers in DACH' is a claim you can defend in a first line. 'Recently active' is not.
- 02
Run the signal endpoint on a schedule you own: a cron, a Lambda, a GitHub Action.
There is no alerting product here and no saved search; the schedule is yours.
- 03
Dedupe to accounts before you spend anything on people.
Twenty job posts from one company is one account, and clean_domain at 0.5 credits per call will normalise the messy ones.
- 04
Filter the account list against your ICP by hand or with /use-cases/icp-filter-with-ai-enrich before the finder runs. Every account you drop here saves a finder call.
- 05
Run email_finder, then email_verifier on the hits.
Both are waterfall endpoints, so a leg that finds nothing costs nothing.
# Leg 1 — the signal. Per-result billing: this bills on a 2xx even
# if the result array comes back short.
curl -s https://api.richapi.ai/api/v1/linkedin_job_search \
-H "x-api-key: $RICHAPI_KEY" \
-H "content-type: application/json" \
-d '{
"title": "Solutions Engineer",
"location": "Germany",
"experienceLevel": "mid_senior_level",
"page": 1
}'
# Leg 2 — people at the companies the signal surfaced.
curl -s https://api.richapi.ai/api/v1/linkedin_company_employees_search \
-H "x-api-key: $RICHAPI_KEY" \
-H "content-type: application/json" \
-d '{"company": "acme", "job_title": ["Head of Revenue Operations"]}'
# Leg 3 — the waterfall. A miss here returns 2xx with
# success:false, billed:false, and costs zero credits.
curl -s https://api.richapi.ai/api/v1/email_finder \
-H "x-api-key: $RICHAPI_KEY" \
-H "content-type: application/json" \
-d '{"first_name":"Dana","last_name":"Weiss","company_domain":"acme.com"}'
Signal-based prospecting: build the list from what companies did, not from what a database thinks
Most outbound lists are built the wrong way round. You pull every company matching a firmographic filter, enrich all of them, and then hunt for a reason to write. The reason arrives last and it shows.
Flip it. Start with an observable event: a company posted a role, a company is running ads, someone at the company wrote about a problem you solve. Let that event decide who is on the list at all. The chain is four calls deep: signal, accounts, people, contact details.
These are signals, not intent data
Say the honest version out loud, because the category is full of people who don't. We do not sell intent data. There is no bidstream, no IP-to-company de-anonymisation of your website traffic, no third-party topic surge score, and no model here telling you a company is 73% likely to buy.
What you get is public activity, fetched live: job posts, ad libraries, LinkedIn posts, company page changes. A company hiring three implementation engineers is evidence about that company's next quarter. It is not a buying signal, and anyone selling you the inference as a fact is selling you a guess with a confidence interval painted on.
In practice, intent data claims to tell you who is in market. A signal tells you what happened, and you supply the inference. That's a worse product and a more defensible first line, because the thing you cite is checkable by the person reading it.
If you need real intent data, buy it from a vendor that has it, and use these endpoints for the part they're good at, which is narrowing the account list before you spend money enriching it.
Which signal endpoint for which motion
linkedin_job_search— hiring as a proxy for a team that is growing or a gap that is open. Billed per result at 0.1 credits per result.linkedin_ad_searchandmeta_ads_library_scraper_sync— who is spending on demand gen right now. 1 credits per result.post_keyword_search— people writing about your problem space this week. 6 credits per result, the most expensive signal in the catalog per row, so page it tightly and never run it exploratory.linkedin_company_posts— what one account is publishing. 0.2 credits per result.
All of these are per-result and all of them bill on a 2xx. A query that matches three things bills for three things. A query that matches nothing still ran, so treat a broad exploratory query as a cost, not a free look.
The failure mode: signal decay
The chain works and then quietly stops working, and it stops for one reason. You wrote the signal query in March, it returned 40 good accounts, and you left it running. By July it returns the same 40 accounts every week, because a job post that was up in March is still up in July, and your dedupe key is the company.
Keep the timestamp. Dedupe on the signal, not the account, and expire a signal after a window you pick: two weeks for posts, a month for jobs, a quarter for ads. A re-contact off a stale trigger reads worse than no contact, because the prospect knows exactly how old the thing you mentioned is.
The second failure mode is running the finder before the filter. email_finder at 5 credits per call is where the spend lives. Every account you drop before that leg is money you keep, and a miss costs you zero anyway, so the expensive mistake is not missing, it is finding an email for someone you were never going to write to.
Where signal-based prospecting goes wrong
There is no UI here. No saved searches, no alerting, no dashboard of triggers turning green. You own the cron, the dedupe table and the decision about what a signal means. If you want that clicked together for you, a workflow tool is a better purchase than an API.
We also do not send anything. The chain ends with a verified address in your own store; the sequencer is yours.
Signal-based prospecting FAQ
Is a job post intent data? No. It is a public fact about hiring. Any inference from it to a buying decision is yours, and you should be able to defend it in one sentence to the person you're writing to.
Which signal converts best? We don't know, and neither does anyone quoting you a number. Run two for a month against the same ICP and compare reply rates on your own data.
What happens if the signal query returns nothing? It bills. Per-result endpoints charge on a 2xx response, and a 2xx with an empty array is still a call that ran. Only the waterfall endpoints endpoints (email_finder, email_verifier, phone_finder) return zero-cost misses.
Can I run the whole chain from Claude? Yes, through the MCP server. See Claude and agent driven account research. The schedule is still yours.
Do I need a card to try it? No. 100 free credits on signup, which is enough to run one narrow signal query and finish the chain on a handful of accounts.
Where to go after signal-based prospecting
More plays on the use cases hub. Chain this into list build and verify for the build order, and waterfall email then verify for the cost model on the last two legs. Endpoint detail lives at email finder and people search. Credit tiers are on pricing.
100 free credits, no card. Pick one signal, run it, and see how much smaller your list gets.
FAQ