Create Job Change Watchlist signal

Watch a fixed list of people and get a lead the moment one of them changes job - reach your champion in their new seat while they still have a mandate to change things.

Where the Job Changes signal DISCOVERS movers matching a persona, this one starts from your list: your champions, your buyers, your lapsed prospects.

Input: profiles - the people to watch. Each entry is either a LinkedIn profile URL on its own, or an object {url, currentTitle, currentCompany} carrying the role you already have on file; both forms can be mixed. Send the role when you have it. Every check is billed, the first one included. With a role on file, the first check compares against it and reports any change straight away. With a bare URL, the first check can only report a move made in the last 6 months (it compares the current job with the one before it); anyone who moved earlier stays invisible - recorded as they stand today - and a later move is reported at the next check - one cadenceHours later, a week by default. A bare URL with cadenceHours: 0 therefore only ever reports moves from the last 6 months. Then detectionMode (company - default - fires only on an employer change; title on a new role at the same employer; both), cadenceHours (how often each person is re-checked: 24, 168 - the default - 360, 720, 1080, 1440 or 2160; 0 checks the list once and never again), addedProfilesLookback (first_run - default - gives a bare URL added later the same 6-month look-back as the initial list; recent_only only records where they stand and reports moves from the next check on), plus enrichment flags (getEmails, getPhones).

Output: the create response carries a watchlist object telling you how many profiles are actually being watched and how many were rejected. From then on, each confirmed change is delivered to your webhookUrl as a person-lead: signal carries previous_title / previous_company alongside new_title / new_company, new_job_started_on ("MM/YYYY", the date to test a change against - previous_job_ended_on differs whenever there was a gap between the two jobs), new_job_start_month (the same month as "YYYY-MM", sortable) and change_type (company, title or both), while contact and company describe the person in their NEW role. The previous_* / new_* / change_type keys are a stable contract: present on every change, never renamed or null, "" when a value is unknown - safe to map straight into your CRM. A change is delivered once, and the new role becomes the baseline for the next check.

profiles is consumed into the watchlist, so it is NOT echoed back in the config of this or any later response — the watched list has exactly one home. Read it with GET /api/v1/watchlists/{signalId}/profiles, and add or remove people with POST / DELETE on the same path, without recreating the signal.

Use cases:

• Follow your champions - when someone who already bought from you moves to a new company, you get a warm intro into an account with a decision-maker who has used your product before.
• Protect renewals - when your day-to-day contact leaves an account, you learn the day it happens instead of at renewal, in time to build a relationship with their replacement.
• Re-time a dead deal - a prospect who said no because of budget or an incumbent tool arrives somewhere new with a fresh stack and a mandate to change things; the objection left with the old job.