Tracker

We built Tracker to watch companies and people on LinkedIn so you don't have to. Add entities to a list, pick rules — "headcount grew 20%", "person changed company", "new funding round" — and we re-check everything on your schedule. When a rule matches, you get a signal: pushed by webhook and stored for the API. You declare what matters; the watching, comparing, and noise-filtering happen for you.

Core concepts

A rule fires only when tracked data actually changes in a way that matches — a refresh that finds nothing produces nothing.

How monitoring behaves

• The first check is a baseline. When you add an entity, its first check snapshots the current state and fires nothing — there's nothing to compare against yet. Signals start from the second check onward, about one refresh interval after the baseline: a daily list added today can fire its first signals tomorrow, a weekly list about a week in. A fresh list with no immediate signals is behaving correctly. (Want history on day one? See day-one signals.)
• The list sets the cadence. Every entity in a list is re-checked on the list's refresh interval, and scheduled runs land overnight US-Pacific time — mornings show fresh data. New entities — and a brand-new list's first run — are picked up by an hourly scheduler, so baselines land within about an hour of adding; they never delay the entities already tracked. getTrackerCompanyList / getTrackerPersonList return nextRefreshAt, so you always know when the next scheduled run is.
• You can refresh on demand. refreshTrackerCompanyList / refreshTrackerPersonList re-checks a list immediately, at most once every 12 hours per list. Use getTrackerOverview first to see what the run will cost.
• We tell you before and after scheduled runs. Subscribe to tracker.list_run_upcoming (about a day ahead) and tracker.list_run_completed at Webhooks.

Day-one signals (initial look-back)

A brand-new list doesn't have to start silent. Pass initialSignals when you add entities (or save rules) and we look backward — up to 30 days — and fire signals for recent events that would have matched: funding rounds, matching job postings, news, posts, acquisitions, new investors, layoffs. Set lookbackPeriodDays explicitly: the default is your refresh interval, so a daily list only looks back one day unless you say otherwise.

Look-back only works for rules anchored to dated events — 15 of the 52 types:

new_funding_round, funding_stage_changed, job_posting_with_keyword, job_posting_in_function, news_with_keyword, company_news, company_posted, company_posted_with_keyword, acquired_company, new_investor, recent_layoffs, person_posted, person_posted_with_keyword, person_reacted_to_post, person_commented_on_post

Diff-based rules (headcount thresholds, title changes, profile edits) need a before and an after, so they start from the second check as usual — unsupported rules come back listed in skippedRules, nothing fails. listAvailableTrackerRules marks every rule with supportsInitialSignals so you can check programmatically.

Day-one signals are billed per entity, only on success, and they seed the baseline — the first scheduled refresh won't re-fire the same events.

Limits

Billing

• 2 credits per entity per refresh at the standard rate. 500 companies checked weekly ≈ 1,000 credits/week. See Billing & credits.

• Volume and frequency earn automatic discounts:

  Rate	Credits / entity / refresh	When it applies
  Standard	2	default
  Scale	1	10,000+ tracked entities or a daily interval
  Bulk	0.5	10,000+ tracked entities and a daily interval

  Tiers apply on their own — no plan change needed. On-demand refreshes bill at the Standard or Scale rate.

• Premium rules set a floor. Eight premium rules watch news coverage and LinkedIn activity on every refresh, so a list containing at least one bills at minimum the Scale rate (1 credit / entity / refresh) — the Bulk discount never drops below it. Standard-rate lists are unaffected, and the floor applies once per list no matter how many premium rules it carries.

• Free: adding entities, reading signals, managing lists, dummy signals, payload previews. (Opting into day-one signals is the exception: those bill per entity, on success.)

• Charged per refresh, never per signal — a refresh firing five signals costs the same as one firing none.

• Out of credits? Nothing breaks. If your balance can't cover a run, we skip it before charging anything — no partial runs, no backlog of surprise charges. The list retries daily instead of waiting out its full interval, and tracking resumes on its own once you top up.

• Forecast spend with getTrackerOverview (GET /v1/tracker/overview): every list, its rules, an upcoming-refresh timeline, and estimated daily/monthly credit burn.

• Pause a list (isActive: false) to stop charges without losing anything.

Rule mechanics

• Per-item rules emit one signal per detected item (posts, news, job postings, funding rounds) — webhook volume can fan out. Aggregated rules (headcount, title changes) emit one signal per entity per refresh.
• Updating rules — two modes, never mixed: pass trackingRules to replace the whole set, or addRules / removeRuleIds for granular edits. Combining them in one request returns a 400 — the guard exists so a small edit can't accidentally wipe your rule set.
• Rule identity survives edits. Saving a list keeps the same ruleId for rules you didn't change, so signal history and integrations keyed on ruleId stay intact.

Company rules

Example:

{
  "type": "new_funding_round",
  "entityType": "company",
  "minAmountUsd": 10000000,
  "roundTypes": ["series_b", "series_c"]
}

Person rules

That's the full catalog: 25 company rules and 27 person rules. Direction rules take direction (entered/exited, started/stopped, or either); keyword rules take match lists. The full field schema for every rule is in the API reference — listAvailableTrackerRules (GET /v1/tracker/rules) returns it programmatically.

Premium rules

Eight rules watch more than the base profile — on every refresh we also monitor news coverage and LinkedIn activity for each tracked entity:

• A list containing at least one premium rule bills at minimum the Scale rate — see Billing. The floor applies once per list: one premium rule or eight, same per-entity rate.
• Mix premium and standard rules freely within the 25-rules-per-list limit.
• Spot them programmatically: listAvailableTrackerRules (GET /v1/tracker/rules) returns isPremium for every rule type, and the getTrackerOverview estimates already reflect the floor — you see the true per-refresh cost before a premium rule ever runs.

Recipes

• Buying intent (companies): job_posting_with_keyword ("data engineer")
  • headcount_growth_percent (15%+) + new_funding_round ($5M+) — any one means spending; all three together is a very strong signal.
• Champion tracking (people): person_changed_company + person_got_promoted + person_open_to_work — a champion who moves companies is a warm intro to their new org.
• Fundraise timing (companies): headcount_growth_percent (30% over 90 days via lookbackDays) + job_posting_in_function (Finance, Legal) + recently_hired_with_title (CFO, VP Finance).

Signals & noise

Tracker is conservative by design — it alerts on real changes and stays quiet otherwise:

• Small fluctuations don't fire. A one-person headcount wobble won't trigger a growth rule.
• The same signal doesn't fire twice. Within a rule's lookback window we suppress repeats, and flip-flop states ("open to work" toggling on and off) are debounced for a week.
• Missing data isn't a change. A temporarily unavailable field is treated as unknown, never as "went to zero" — no false "person left their company" alerts.
• Promotions and demotions are verified before firing, so cosmetic title edits don't get mislabeled.
• Every signal carries a confidence score (0–1). Deterministic rules report 1.0; interpretive ones report model confidence so you can weight them in your automations.

Consuming signals

Webhooks (real-time). A firing rule delivers a tracker.signal_detected webhook — a self-contained envelope with the entity, the matched rule, a human-readable summary, structured changeData, source URLs (sources), a methodology note, the real-world eventDate where one exists, and confidence:

{
  "eventId": "evt_...",
  "occurredAt": "2026-06-02T12:00:00.000Z",
  "entity": { "type": "company", "identifiers": { "linkedinSlug": "example-co", "domain": "example.com" } },
  "subscription": { "type": "headcount_crossed_threshold", "listName": "Target Accounts" },
  "signal": { "summary": "Headcount crossed 100 (now 104)", "confidence": 1.0, "isDummy": false }
}

eventId is stable across retries — dedupe on it. Configure the endpoint at fiber.ai/app/webhooks; see Webhooks for signatures and retries.

API polling (the reliable fallback). Every signal is stored whether or not a webhook exists — read them with listTrackerSignals (GET /v1/tracker/signals/{listId}) or listTrackerChanges (GET /v1/tracker/changes/{listId}), using since (ISO timestamp), cursor, limit (1–100), and includeDummy. Reading signals is free. A robust integration does both: webhooks to react now, polling with since to backfill anything missed.

Testing tools (both free):

• fireTrackerDummy (POST /v1/tracker/fire-dummy/{listId}) — mark rules isDummy: true and fire synthetic signals through your real webhook, flagged isDummy: true, as often as you like.
• previewTrackerSignal (POST /v1/tracker/rules/preview-signal) — send a rule, get an example payload. Nothing is created, nothing is delivered.

Managing lists

• Pause/resume: isActive: false stops refreshes and charges; rules, interval, and history are preserved. Flip back to resume.
• Remove an entity: stops its future checks and charges; signal history is preserved. Re-adding the same entity later does not reset its baseline — a genuinely new entity starts fresh.
• Delete a list: deactivates the list and everything in it; signal history is retained.

API quick reference

All operations are under /v1/; each links to its focused reference page in the operation index.