Signals

Create M&A Watchlist signal

Get told when a company on YOUR list is acquired, or acquires someone. Being bought puts an account's whole stack under review; buying means budget and a system to integrate. Both are openings, and you choose which to hear about with watchSide.

Where the M&A signal always prospects the acquirer, here the lead is always YOUR company - whichever side of the deal it was on - and signal.deal_role tells you which. There is deliberately no company-size, location or industry filter: you named the companies, which answers that far more precisely than an ICP could, and re-filtering your own list could only drop accounts you asked us to watch.

Input: companies (names, domains or LinkedIn company URLs), watchSide (acquiree / acquirer / both, default both), dealTypes, minAmount (USD), announcedPeriod (default 30d), plus optional persona targeting (enablePersonaTargeting, targetPersonas, maxLeadsPerCompany).

Output: each qualifying deal is delivered to your webhookUrl. A deal between two watched companies delivers BOTH, once each, distinguished by signal.deal_role.

Persona targeting changes WHAT you receive; it does not add to it. Left off, a deal delivers one company-level lead carrying no contact. Turned on, that company lead is REPLACED by one lead per matching person at the company - so a deal that would have sent one payload can send several, or none at all if nobody matches. maxLeadsPerCompany caps how many; personaExportMode chooses between the best-ranked contacts (the default) and every match. Persona leads are billed per person found, not per deal.

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:

  • Your champion got bought - the acquiree's stack goes under review within weeks; reach them while it is still their decision.
  • Your account went shopping - an acquirer has budget and a freshly inherited system to integrate, which is a services and tooling opening.
  • Protect the base - watch your own customers so you learn about a deal from us rather than from a churn notice.
post/api/v1/signals/mergers-acquisitions-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/mergers-acquisitions-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": {
    "announcedPeriod": "30d",
    "companies": [
      "Doctolib",
      {
        "domain": "payfit.com",
        "linkedinUrl": "https://www.linkedin.com/company/payfit",
        "name": "PayFit"
      }
    ],
    "dealTypes": [
      "acquisition"
    ],
    "getEmails": true,
    "watchSide": "both"
  },
  "dailyLeadLimit": 20,
  "name": "M&A at my accounts",
  "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.