Signals

Create New Decision Maker Watchlist signal

Get told when a new decision maker takes a role at one of your accounts - reach them while the seat is still being shaped, before the incumbent's supplier list has settled.

Where the Job Change watchlist follows PEOPLE you already know and tells you when they move, this one follows your COMPANIES and tells you who arrived. The person is the discovery: you do not need to have heard of them for the signal to find them.

Input: companies (a name, a domain, or a LinkedIn company URL per entry - send the LinkedIn URL whenever you have it, it is the only one of the three that separates two companies sharing a name - or an object {name, domain, linkedinUrl} carrying all three; strings and objects can be mixed), targetPersonas (which roles count as a decision maker) and optional customJobTitles for titles your industry uses that the standard personas do not cover, cadenceHours (default 24), dailyLeadLimit (default 25), plus enrichment flags (getEmails, getPhones).

Output: each person arriving into a matching role at a watched company is pushed to your webhookUrl as an enriched person-lead: a signal object, a contact object (name, new title, LinkedIn URL, matched persona, and email/phone when enrichment is on) and a company object for the account they joined. The first check returns everyone who has recently arrived; each check after that returns only what is new since the last, so an arrival is delivered once.

At least one of targetPersonas or customJobTitles is required - without a role filter the signal would return every job change at every watched company, which is the volume mode this signal exists to replace.

companies 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}/companies, and add or remove companies with POST / DELETE on the same path.

Use cases:

  • Land before the incumbent does - a new decision maker has no supplier loyalty yet and is actively rebuilding their stack; the first weeks are the widest the window ever gets.
  • Re-open a lost account - the person who chose against you has left, so the objection left with them; the arrival resets the evaluation.
  • Warm your own customer base - when a new leader takes over an account you already serve, reach them before they inherit an opinion of you from someone else.
  • Route to the right rep on arrival - push the arrival into your CRM against the account it belongs to, so ownership and sequencing happen the day it lands.
post/api/v1/signals/new-decision-maker-watchlist

Request

  • Base URL: https://api.rodz.io (the document declares no server; this is the origin it was published from)
  • URL: https://api.rodz.io/api/v1/signals/new-decision-maker-watchlist
  • Auth: HTTP bearer

Request body

namestring required

Name for this signal

webhookUrlstring nullable

Where each lead is POSTed as it is produced. Optional (since 2026-09-23): omit it when you read leads with GET /api/v1/signals/{signalId}/leads or route them to a connected CRM or sequencer with destinations on PATCH /api/v1/signals/{signalId}.

dailyLeadLimitinteger

Max leads per day

statusstring nullable

Initial status (default: draft).

Example request

{
  "config": {
    "cadenceHours": 24,
    "companies": [
      "https://www.linkedin.com/company/doctolib",
      {
        "domain": "payfit.com",
        "linkedinUrl": "https://www.linkedin.com/company/payfit",
        "name": "PayFit"
      },
      "Lemlist"
    ],
    "customJobTitles": [
      "Head of Revenue Operations"
    ],
    "dailyLeadLimit": 25,
    "getEmails": true,
    "targetPersonas": [
      "Sales Director",
      "CTO"
    ]
  },
  "name": "Comptes strategiques - arrivees",
  "status": "active",
  "webhookUrl": "https://example.com/webhooks/rodz"
}

Response

Signal created

idstring required
namestring required
statusstring required
signalTypeIdstring required
webhookUrlstring nullable
configobject nullable

Signal-specific configuration

dailyLeadLimitinteger required
leadsTodayinteger required
leadsTotalinteger required
duplicateHandlingstring required

Duplicate lead handling: 'refuse' (never accept), 'allow' (always accept), or 'Xd' (accept after X days)

createdAtstring required
updatedAtstring required
lastLeadAtstring nullable
appliedobject

Settings this signal runs with where they differ from config, keyed like config. {} when every stored setting is applied as stored. A null value means the stored field is not used by this signal. Every entry is explained by a warning naming the same field.

Example response

{
  "applied": {
    "allowUnknownCompanySize": false,
    "maxJobAgeDays": 180
  },
  "config": {
    "companySizeFilters": [
      "201-500",
      "501-1000"
    ],
    "getEmails": true,
    "jobTitles": [
      "CTO"
    ],
    "locations": [
      "France"
    ],
    "maxJobAgeDays": 90
  },
  "createdAt": "2026-01-15T10:30:00Z",
  "dailyLeadLimit": 50,
  "duplicateHandling": "refuse",
  "id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "lastLeadAt": "2026-03-15T14:22:00Z",
  "leadsToday": 3,
  "leadsTotal": 127,
  "name": "CTOs changing jobs in France",
  "signalTypeId": "job_changes",
  "status": "active",
  "updatedAt": "2026-03-16T08:00:00Z",
  "warnings": [
    {
      "code": "VALUE_BELOW_MINIMUM",
      "field": "maxJobAgeDays",
      "message": "`maxJobAgeDays` is 90; this signal applies 180. Job changes are delivered up to 180 days after the start date, and a shorter window is raised to that minimum.",
      "severity": "info",
      "values": [
        "90"
      ]
    }
  ],
  "webhookUrl": "https://your-server.com/webhooks/rodz"
}

Changes

No recorded changes to this operation across all 1 revision of this API.