Signals | Signal docs

A signal is an event that a monitor found for a campaign, for example a funding round or a leadership change. Signals are read-only. Monitor runs create them. The API has no operation that creates, changes or deletes one signal. The organization owns the signal. Campaign provenance is optional; subjects can exist without account or person records.

This page describes the current contract. Monitor targets and signal subjects describes organization ownership, subject identifiers and historical retention in this candidate.

The signal object

Field	Type	Description
`id`	UUID	Required. ID of the signal.
`campaign_id`	UUID	Nullable. Retained source campaign provenance.
`person_ids`	UUID array	Existing people linked to the signal.
`subjects`	string array	Stable subject references, independent of prospect records.
`account_ids`	array of UUID	IDs of the accounts that the signal is about. Empty for a topic signal and for a signal about people only.
`summary`	string	Required. What happened.
`signal_type`	enum	Required. Category of the event. See Signal types.
`signal_display_name`	string	Nullable. Display name of the signal type in the monitor config.
`strength`	enum	Nullable. Importance of the signal: `LOW`, `MEDIUM` or `HIGH`.
`score`	number	Nullable. Probability of a sales opportunity, from 0.0 to 1.0.
`references`	array of string	URLs of the sources.
`metadata`	object	Nullable. Data that is specific to the signal type.
`monitor_id`	UUID	Nullable. ID of the monitor that found the signal. Null for an older signal with no monitor.
`event_date`	date	Nullable. Date of the event, `YYYY-MM-DD`. Null when the source gives no date.
`created_at`	timestamp	Required. Time when the monitor found the signal.

{
  "id": "1b2c3d4e-5f6a-4b7c-8d9e-0f1a2b3c4d5e",
  "campaign_id": "3f2b8a4e-1c5d-4e7f-9a0b-6c2d8e1f4a7b",
  "account_ids": ["8c1d2e3f-4a5b-4c6d-8e7f-9a0b1c2d3e4f"],
  "summary": "Acme raised a 20 million USD Series A.",
  "signal_type": "funding",
  "signal_display_name": "Funding",
  "strength": "HIGH",
  "score": 0.82,
  "references": ["https://example.com/acme-series-a"],
  "metadata": null,
  "monitor_id": "9a8b7c6d-5e4f-4a3b-8c2d-1e0f9a8b7c6d",
  "event_date": "2026-09-22",
  "created_at": "2026-09-23T12:00:00.000Z"
}

Signal types

signal_type has 17 values. The same values are valid for signal_types[].type in a monitor config.

Value	Events
`funding`	Investment rounds, grants or other capital raises.
`leadership_change`	Changes in executive leadership, the C-suite or the board of directors.
`layoff`	Workforce reductions, downsizing or restructuring.
`product_launch`	New products, services or major feature releases.
`partnership`	Strategic partnerships, alliances or integration announcements.
`acquisition`	Mergers and acquisitions, as buyer or target.
`expansion`	Geographic expansion, new market entry or office openings.
`award`	Industry awards, recognitions, certifications or rankings.
`pivot`	Major business model changes or strategic direction shifts.
`regulatory`	Regulatory compliance updates, legal matters or policy changes.
`rfp`	RFP issuance, vendor evaluations or the start of a procurement process.
`contract_renewal`	Contract renewals, renegotiations or upcoming expirations.
`hiring_surge`	Unusual hiring activity.
`infrastructure`	Infrastructure incidents, upgrades or technology changes.
`compliance`	New compliance requirements, audit pressures or certification needs.
`job_posting`	A single job posting.
`other`	Other business events. A monitor uses `other` for a custom signal type.

Strength and score

strength is the importance of the signal. The values are upper case: LOW, MEDIUM and HIGH.
score is the probability of a sales opportunity, from 0.0 to 1.0.
Both fields can be null.
list_signals can filter on strength. It has no filter on score.

Lifecycle

A monitor run creates signals. The run result.completed is the number of signals that the run processed.
delete_monitor deletes the signals that the monitor found.
delete_campaign retains signals and their source provenance.

Search

list_signals lists the signals of the organization, oldest first. Send order=desc for the newest first. Use created_after or days to read recent signals. It takes these filters:

Filter	Description
`campaign_id`	Signals with this campaign provenance, including retained history. An unknown campaign gives 404.
`person_id`	Signals about an existing person of the organization.
`account_id`	Only the signals about this account. An unknown account gives 404.
`signal_type`	Only the signals of this type.
`strength`	Only the signals of this strength.
`search_term=<text>`	Only the signals whose summary or type contains the text. The text has 1 to 200 characters.
`monitor_id`	Only the signals of this monitor. An unknown monitor gives 404.
`created_after`	Only the signals created at or after this time, an RFC 3339 string.
`days`	Only the signals of the last number of days, 1 to 365. Without it, the list has no time limit. With `created_after`, the later time applies.
`order`	`asc` (default) for the oldest first, `desc` for the newest first. Keep the same `order` with a `cursor`.
`limit`, `cursor`	Pagination. Read Paginate and handle errors.

When an account leaves the campaign that produced a signal, the signal stays. account_ids no longer includes that account, and the account_id filter no longer finds the signal.

Operations

Each path below follows $LINKT_API_URL/v2. Set LINKT_API_URL to the origin only, for example https://api.signal.linkt.ai.

Operation	Method and path	Purpose
`list_signals`	`GET /signals`	List the signals of the organization.
`get_signal`	`GET /signals/{signal_id}`	Get one signal.

curl --fail-with-body --request GET "$LINKT_API_URL/v2/signals/$SIGNAL_ID" \
  --header "x-api-key: $LINKT_API_KEY"

API reference: get_signal

curl --fail-with-body --request GET "$LINKT_API_URL/v2/signals?limit=5" \
  --header "x-api-key: $LINKT_API_KEY"

API reference: list_signals

APP-483 candidate fields

The coordinated release adds subjects, person_ids, and event_date. Subject references identify observed subjects independently of prospect records. Account and person IDs refer only to existing records. Reading a signal does not convert its subject into a prospect. A person's known account relationship is included when available.

campaign_id becomes nullable provenance. Historical values and signal UUIDs remain unchanged after source deletion. event_date is null when unknown; created_at records when the observation was saved. Keep these dates distinct. Evidence remains in references and metadata.

Set person_id to an existing person UUID to read that person's signals. The UUID below is illustrative; replace it with your person's ID.

curl --fail-with-body --request GET "$LINKT_API_URL/v2/signals?limit=5&person_id=$PERSON_ID" \
  --header "x-api-key: $LINKT_API_KEY"

API reference: list_signals

These additions describe the APP-483 candidate, pending coordinated runtime activation. The downloaded contract identifies the exact backend candidate.

On this page