A buying signals API returns the companies or people where a measurable change just happened, delivered as structured JSON. You pick the signal, the look-back window, and the strength. It sends back the list.
I wish someone had handed me that sentence in Hamburg in 2019. Back then I kept a browser folder of 40 target companies and re-read their pages every Friday, hunting for anything new. I still missed a funding round by five weeks. A faster vendor got the deal.
So this page is the tour I needed: what these endpoints actually take, what they actually return, and working calls you can paste today.
📌 TL;DR: Four POST endpoints at api.cufinder.io/v2/ (caa, psa, csa, jca), all authenticated with an x-api-key header. The signal endpoints filter by signal_name (99 types), time_frame (7, 30, 90, or 180 days), and bucket (low, moderate, high, hyper). Requests cost 1 to 2 credits each and return a { "status": 1, "data": { ... } } envelope.
What is a buying signals API?
A buying signals API is an endpoint that reports timestamped changes in a company or a person, not static facts about them. Firmographics tell you who a company is. A signal tells you something just moved: a funding round, a new VP of Sales, a hiring spike.
“A static lead list tells you who a company is. It never tells you when to call them.”
CUFinder Signals APIs documentation
Under the hood, the mechanic is simple to describe. Company pages, job postings, employee profiles, and funding records get crawled and stored as point-in-time snapshots. Each new crawl is compared against the previous one. When a tracked field differs, a deterministic trigger evaluates the change, a magnitude gets assigned, and the signal is emitted with its metadata.
CUFinder’s graph tracks 99 signal types across 10 categories: 70 company signals, 17 people signals, and 12 composite patterns. The graph refreshes daily against 1B+ people profiles and 85M+ company profiles. And because every quantitative signal also carries a magnitude level, those 99 types multiply out to 1,000+ distinct signal variations you can filter on.
This page is the plumbing. The strategy side (which signals mean what, and what to send when one fires) lives in our buying signals guide. Here, we stay close to the JSON.
Buying signals API vs intent data API
Intent data infers interest from browsing behavior. A buying signals API reports observed public changes. That is the whole distinction, and it matters more than vendors admit.
Classic intent products score accounts on content consumption: which topics a company’s employees research across publisher networks. Bombora built the best-known co-op for this, and review platforms sell their own flavor, like G2’s buyer intent feed of who viewed your category page. The signal is broad and early. But it is inferred. Nobody can show you the click.
Signals data works the other way around. A funding announcement, a leadership hire, an office opening: these are events anyone can verify by looking at the company’s public page. So coverage is narrower (quiet companies emit fewer signals), but every record comes with evidence attached.
To be plain about what we are not: CUFinder’s endpoints are not bidstream intent. No topic scores, no anonymous research surges. If your motion needs both, run both. They stack well because they fail differently.
Can you do this without an API?
Yes, at small scale you honestly can. Follow your target accounts on their professional network pages. Check careers pages weekly. Set Google Alerts for funding news. Subscribe to a funding newsletter for your region. Under 20 accounts or so, a disciplined Friday routine catches most of what matters.
The next step up is building detection yourself, and this is where the estimate gets real. You need a crawler, a snapshot store, diff logic, rolling baselines so one noisy week doesn’t page you, and monitoring for the pipeline itself. Data engineers know this pattern as change data capture, applied to public pages instead of your own database. Building it is genuinely fun. Keeping it alive is not.
I know because mine died quietly for eleven days. More on that below.
The four endpoints at a glance
Every endpoint is a POST to https://api.cufinder.io/v2/<code>, authenticated with an x-api-key header (your key lives under Account, then API key, in the dashboard). And every response arrives in the same { “status”: 1, “data”: { … } } envelope, with a page parameter supported across all four.
| Endpoint | POST path | Required inputs | Returns | Credits/request |
|---|---|---|---|---|
| Company Activity | /v2/caa | query (name, domain, or profile URL) | activities[]: recent social posts | 2 |
| People Signals | /v2/psa | signal_name, time_frame, bucket | contacts[]: people at signaling companies | 2 |
| Company Signals | /v2/csa | signal_name, time_frame, bucket | companies[]: firmographics + the signal | 2 |
| Job Changes | /v2/jca | start_date, end_date, type | job_changes[]: from/to records | 1 |
Notice the split. Two endpoints answer “where did signal X fire?” (one returns companies, one returns the people at them). One tracks role moves across a date range. And one pulls a single company’s posting feed. Different questions, same contract.
time_frame and bucket: the two filters that do the work
The signal endpoints take just three required parameters, and two of them decide everything about result quality. time_frame is the look-back window in days: 7, 30, 90, or 180. bucket is the signal strength, computed from the percentage delta between snapshots.
| Bucket | Change between snapshots |
|---|---|
| low | 1% to just under 5% |
| moderate | 5% to just under 15% |
| high | 15% to just under 30% |
| hyper | 30% or more |
Because the basis is a percentage, magnitude scales with company size. One hire at a 10-person shop buckets far higher than one hire at 5,000 people. Categorical events (a size-band upgrade, a first job in a new function, a drastic rename) are treated as high-signal regardless of any percentage. The full math lives in the magnitude buckets reference.
Window choice matters just as much. Some signals fire instantly between two crawls, others clear 90-day or 180-day patterns, and the detection timeframes page maps which is which. The docs put the practice rule nicely: the longer the window a signal clears, the longer your outreach stays relevant.
💡 Starting policy: alert on high and hyper only, then widen to moderate for the two or three signals that map straight to your buyer. That is the docs' own recommendation, and it holds up in practice.
Company Signals API: companies where a signal fired
So what does a call actually look like? Here is the Company Signals reference example, verbatim, with the response trimmed for length (field names untouched):
curl -X POST https://api.cufinder.io/v2/csa \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"signal_name": "employee_growth", "time_frame": 30, "bucket": "low", "page": 1}'
# response (trimmed)
{
"status": 1,
"data": {
"confidence_level": 95,
"query": { "signal_name": "employee_growth", "time_frame": 30, "bucket": "low", "page": 1 },
"companies": [
{
"name": "google",
"website": "https://google.com",
"domain": "google.com",
"employees": { "range": "10001+" },
"industry": "software development",
"type": "public company",
"main_location": { "country": "united states", "state": "california", "city": "mountain view" },
"signal": { "name": "employee_growth", "time_frame": 30, "bucket": "low" }
}
],
"credit_count": 4757
}
}Each company arrives with its firmographics plus the exact signal object that triggered its inclusion. Swap employee_growth for whatever maps to your product: funding_round_announced if you sell to newly funded teams, sales_leader_hire if a new sales leader is your opening. Any of the 99 signal keys works here.
People Signals API: the people at those companies
That’s the company side. The people side returns the humans behind the same change. Same three parameters, but /v2/psa hands back contacts[] instead. Each person arrives with full_name, current_job.title, location and social profiles, a company block, and the signal object.
import requests
resp = requests.post(
"https://api.cufinder.io/v2/psa",
headers={"x-api-key": "YOUR_API_KEY"},
json={"signal_name": "employee_growth", "time_frame": 30, "bucket": "low", "page": 1},
timeout=30,
)
data = resp.json()["data"]
for c in data["contacts"]:
print(c["full_name"], "|", c["current_job"]["title"], "|", c["company"]["name"])The full accordion of all 99 signal_name values sits on the People Signals reference, grouped by category. Bookmark it; it doubles as a taxonomy of everything the graph watches.
One honest limitation. There are no title or geography parameters on these endpoints: signal_name, time_frame, bucket, and page is the whole request. So filter the returned records in your own code. The response gives you titles, industries, and locations to filter on, and that is the intended pattern.
Job Changes API: people who moved
Number four thinks in date ranges instead of look-back windows. POST /v2/jca with a start_date and end_date (YYYY-MM-DD) plus a type: company_change, promotion, lateral_title_change, or no_company_to_company. It costs 1 credit per request and returns job_changes[] records, each with the person’s linkedin_url, a detected_at timestamp, and from/to blocks carrying company and title.
curl -X POST https://api.cufinder.io/v2/jca \
-H "x-api-key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"start_date": "2026-05-15", "end_date": "2026-08-15", "type": "promotion", "page": 1}'This one deserves its own article, and it has one. The Job Changes API deep-dive covers date-range patterns, the four types, and two working recipes, including the weekly champion sweep.
Company Activity API: what they’re posting
And the last endpoint answers a softer question: what is this company talking about right now? Send /v2/caa a query (company name, domain, or profile URL) and it returns activities[]. That’s the company’s recent public posts with text, hashtags, media, posted_at, and reaction, comment, and repost counts. The Company Activity reference shows the full post shape.
Use it for context, not for triggering. A signal tells you WHEN to reach out. The posting feed tells you what language the company is using about itself that week, which is exactly what a first line should borrow.
Three workflows teams actually run
Raw endpoint access is not a workflow. Here are the three patterns I see hold up:
- The weekly priority sweep. Every Monday, a cron job pulls /v2/csa for one buyer-mapped signal with time_frame 7 and bucket high. It ranks the overlap against your account list and posts the top ten to the team channel.
- Trigger-based outreach. Pull /v2/psa for sales_leader_hire with time_frame 90. New leaders rethink their stack in the first quarter; that window is the whole point of the wider time_frame.
- Follow the mover. A weekly /v2/jca sweep with type company_change, matched against your champions list. It pairs naturally with a postings-based motion like the hiring-signals workflow. Postings show a team growing; job changes show who just walked in the door.
Whichever you pick, pair the window with the magnitude. Act fastest on short-window, high-magnitude events. Long-window composites are slower but sturdier.
🧠 Alert on the delta, not the count: 400 open roles at an enterprise is Tuesday. Four new roles on a 40-person team is a signal.
Errors, pagination, and credit math
Three implementation notes will save you an afternoon. First, pagination: pass page and keep incrementing until the results array comes back empty. Second, teach your code three cases. An empty page is normal, a non-200 response earns a retry with backoff (the usual HTTP status semantics), and a malformed body gets logged, not retried. Third, budget: signal and activity requests cost 2 credits each, job-change requests cost 1, and the price is per request, not per row returned.
Every response also echoes your query back and includes a confidence_level, which is useful when you are debugging why a sweep looked thin. And the platform’s documented usage limits apply here like everywhere else, so put a polite pause in your pagination loop.
The cron job I was proud of until March
In 2024 I built the self-hosted version of all this for 300 tracked accounts. A scraper, a snapshot store, a nightly diff. I was genuinely proud of it. Then it died on March 4th, silently, and nobody noticed until March 15th. Eleven days of “no signals this week!” that were actually no crawler.
The embarrassing part? Two of those quiet days contained a funding announcement in our patch. We found it on the company’s page three weeks later, the way I used to find things in Hamburg.
Rebuilding on the signal endpoints took an afternoon. The cadence that stuck: → 300 accounts → one csa pull per buyer-mapped signal, weekly → 12 to 18 flagged accounts → 4 to 6 sends after human triage. Those are my numbers, not a benchmark. But the pipeline has not had a silent death since, because there is no pipeline left to die.
How this page was put together
Every parameter, credit figure, bucket threshold, and response field on this page was checked against the live CUFinder Signals API references on August 22, 2026. The response snippets are the documented examples, trimmed for length with field names unchanged. Workflow numbers are from my own runs and labeled as such. And one limitation stated plainly: signal coverage depends on what companies publish publicly, so quiet companies emit fewer signals. This page documents shapes, not benchmarks we didn’t run.
FAQ
What is a buying signals API?
An endpoint that returns companies or people where a tracked change just fired, as structured JSON. Instead of static firmographics, you get timestamped events (funding, leadership hires, hiring spikes) you can filter by recency and strength.
What are examples of buying signals?
A funding round announcement, a new sales leader, a spike in open roles, a headquarters move, an employee joining from a competitor, or an IPO pattern. In this API those are funding_round_announced, sales_leader_hire, jobs_open_spike, hq_change, employee_joined, and ipo_signal.
Is a buying signals API the same as an intent data API?
No. Intent data infers interest from content consumption and browsing behavior; a signals API reports observed public changes like hires and funding. The intent side is broader but inferred. Signals are narrower but verifiable. Many teams run both.
Which parameters do the signal endpoints accept?
Three required plus pagination: signal_name (any of the 99 keys), time_frame (7, 30, 90, or 180 days), and bucket (low, moderate, high, or hyper), plus an optional page. The Job Changes endpoint differs: start_date, end_date, and type.
How many credits does each request cost?
Company Activity, People Signals, and Company Signals cost 2 credits per request; Job Changes costs 1. Pricing is per request, not per returned row, so pagination multiplies cost by pages pulled.
Can I filter results by industry or location?
Not in the request: the signal endpoints accept only signal_name, time_frame, bucket, and page. But every returned record carries industry, location, and size fields, so the working pattern is to pull first and filter client-side.
How fresh is the data?
Signals are detected by comparing recurring snapshots, refreshed daily against 1B+ people profiles and 85M+ company profiles. Your time_frame controls how far back the query looks, from 7 up to 180 days.
Pull one signal this week
Don’t start with an integration project. Start with one call. → Pick the one signal that maps to your buyer → pull it with time_frame 7 and bucket high → spend 20 minutes triaging the overlap with your accounts → send one honest email. That’s the whole experiment, and it costs 2 credits.
Because the difference between a list and a reason to reach out is timing. You now know exactly where the timing lives. Which signal are you pulling first? I’d honestly love to know what your Monday sweep turns up.
Bad
Okay
Good
Amazing
