Playbooks · Playbook
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.
Last updated September 22, 2026
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.
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.
# 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"}'
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.
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.
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.
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.
Run email_finder, then email_verifier on the hits.
Both are waterfall endpoints, so a leg that finds nothing costs nothing.
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.
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.
- `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_search` and `meta_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 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.
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.
**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 multi-provider waterfall 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](/integrations/claude) and [agent driven account research](/use-cases/agent-driven-account-research). The schedule is still yours. **Do I need a card to try it?** No. 25 free credits on signup, which is enough to run one narrow signal query and finish the chain on a handful of accounts.
More plays on the [use cases](/use-cases) hub. Chain this into [list build and verify](/use-cases/list-build-and-verify) for the build order, and [waterfall email then verify](/use-cases/waterfall-email-then-verify) for the cost model on the last two legs. Endpoint detail lives at [email finder](/api/email-finder) and [people search](/api/people-search). Credit tiers are on [pricing](/pricing). **25 free credits, no card.** Pick one signal, run it, and see how much smaller your list gets.