Watching People for Topic Intent with the Clay CLI

Create a signal that fires when a tracked person researches a topic you care about, using signals create --type PersonTopicIntent, whose provider catalog is company-side-only for one of its three providers.

What you will build

A Paused PersonTopicIntent signal watching a people audience, using a real topic id resolved from a plain-language query.

clay signals search-topics --query <text> --entity-type person
    ↓
{ data: [{ matches: { delivr[], intentsify[] } }] }   ← bombora always empty for person
    ↓
clay signals create --type PersonTopicIntent --input '{"providerConfigs":[{"provider":"intentsify","topicIds":[...]}]}'

AI Prompt

Using the Clay CLI, resolve a person-side topic and create a
PersonTopicIntent signal.

Requirements:
- `clay signals search-topics --query <text> --entity-type person`:
  --entity-type person always returns an empty bombora match array,
  because bombora is company-only. Only delivr and intentsify have
  person-side topics.
- `signals create --type PersonTopicIntent --input '{"entityType":
  "CONTACT","segmentIds":[...],"providerConfigs":[{"provider":<delivr|
  intentsify>,"topicIds":[...],"tiers":[...]}]}'`. Only delivr/intentsify
  are valid providers for this type; a bombora providerConfig here
  validates but is silently ignored at run time (per the CLI's own
  documentation of this type).
- Defaults to a weekly schedule (not monthly, unlike JobChange/Promotion/
  NewHire/JobPost), since the providers refresh weekly, so --schedule for
  this type only accepts quarterly/monthly/biweekly/weekly (no daily).
- The provider set is fixed at creation: update can change a config's
  topicIds/tiers, but adding or dropping a provider requires a new signal.
- Run the verification step below before finishing.

Using the Clay CLI, resolve a person-side topic and create a
PersonTopicIntent signal.

Requirements:
- `clay signals search-topics --query <text> --entity-type person`:
  --entity-type person always returns an empty bombora match array,
  because bombora is company-only. Only delivr and intentsify have
  person-side topics.
- `signals create --type PersonTopicIntent --input '{"entityType":
  "CONTACT","segmentIds":[...],"providerConfigs":[{"provider":<delivr|
  intentsify>,"topicIds":[...],"tiers":[...]}]}'`. Only delivr/intentsify
  are valid providers for this type; a bombora providerConfig here
  validates but is silently ignored at run time (per the CLI's own
  documentation of this type).
- Defaults to a weekly schedule (not monthly, unlike JobChange/Promotion/
  NewHire/JobPost), since the providers refresh weekly, so --schedule for
  this type only accepts quarterly/monthly/biweekly/weekly (no daily).
- The provider set is fixed at creation: update can change a config's
  topicIds/tiers, but adding or dropping a provider requires a new signal.
- Run the verification step below before finishing.

Prerequisites

The clay CLI on PATH, authenticated via clay login (an OAuth session, not a Public API key)
An existing people audience segment

Note: JSON samples below are trimmed to the fields relevant to each step. Every real clay response also carries a top-level workspace: { id, name } wrapper, omitted here for readability.

1. Confirm bombora is always empty for person-side search

clay signals search-topics --query 'data infrastructure' --entity-type person | jq '.data[0].matches'

clay signals search-topics --query 'data infrastructure' --entity-type person | jq '.data[0].matches'

Real output, bombora is empty regardless of query:

{"delivr": [], "intentsify": [{"id": "19962", "name": "Data asset"}], "bombora": []}

{"delivr": [], "intentsify": [{"id": "19962", "name": "Data asset"}], "bombora": []}

2. Create the signal with a real intentsify topic id

clay signals create --type PersonTopicIntent --input '{
  "entityType": "CONTACT",
  "segmentIds": ["audseg_0tjs3u3yAgacWPpe926"],
  "providerConfigs": [{"provider": "intentsify", "topicIds": ["19962"], "tiers": ["high"]}]
}' --name "TPC Batch3: Data infra topic intent"

clay signals create --type PersonTopicIntent --input '{
  "entityType": "CONTACT",
  "segmentIds": ["audseg_0tjs3u3yAgacWPpe926"],
  "providerConfigs": [{"provider": "intentsify", "topicIds": ["19962"], "tiers": ["high"]}]
}' --name "TPC Batch3: Data infra topic intent"

Real output, note the real weekly default schedule:

{
  "runStatus": "Paused",
  "signal": {"type": "PersonTopicIntent", "inputs": {"providerConfigs": [{"provider": "intentsify", "topicIds": ["19962"], "tiers": ["high"]}], "entityType": "CONTACT", "segmentIds": ["audseg_0tjs3u3yAgacWPpe926"]}},
  "schedule": {"periodAmount": 1, "periodUnit": "weekly"}
}

{
  "runStatus": "Paused",
  "signal": {"type": "PersonTopicIntent", "inputs": {"providerConfigs": [{"provider": "intentsify", "topicIds": ["19962"], "tiers": ["high"]}], "entityType": "CONTACT", "segmentIds": ["audseg_0tjs3u3yAgacWPpe926"]}},
  "schedule": {"periodAmount": 1, "periodUnit": "weekly"}
}

Verify the result

Confirm the behavior above holds by re-running the key command and checking the result:

clay signals search-topics --query 'data infrastructure' --entity-type person

clay signals search-topics --query 'data infrastructure' --entity-type person

Expected: bombora matches are always an empty array for --entity-type person; a PersonTopicIntent signal created from a real intentsify or delivr topic id is Paused with a real weekly default schedule.

How it works

PersonTopicIntent and CompanyTopicIntent share almost identical mechanics (create shape, provider immutability, weekly default) but differ in one place: which providers can watch which entity type. Bombora's data model is company-level only, so it has nothing to return for a person-side search. Rather than erroring, search-topics returns an empty array for that one provider, consistent with the CLI's general pattern of returning an empty result over an error when a scope has nothing to offer.

Common issues

Configuring a bombora provider on a PersonTopicIntent signal

Bombora appears as a valid provider value for CompanyTopicIntent, so it's easy to assume it's universal. For PersonTopicIntent, though, a bombora config validates but is silently ignored at run time. Only delivr and intentsify actually watch person-side topics.

Expecting a daily schedule option

Other signal types (JobPost, NewHire, News) accept daily, but topic-intent types (both Person and Company) only accept quarterly/monthly/biweekly/weekly, per the CLI's own validation, because the underlying providers refresh weekly at the fastest.

Next steps

Compare against clay signals create --type CompanyTopicIntent to see the same mechanics applied company-side, where bombora is usable.
Configure two providers on one signal at once; see the dedicated multi-provider example.

verification:
  status: verified
  tested_at: "2026-09-21"
  product_version: "clay CLI 1.2.0"
  command: "clay signals search-topics --query 'data infrastructure' --entity-type person"
  expected_result: "bombora matches are always an empty array for person-side topic search; a PersonTopicIntent signal created from a real intentsify topic id is Paused with a real weekly default schedule."

verification:
  status: verified
  tested_at: "2026-09-21"
  product_version: "clay CLI 1.2.0"
  command: "clay signals search-topics --query 'data infrastructure' --entity-type person"
  expected_result: "bombora matches are always an empty array for person-side topic search; a PersonTopicIntent signal created from a real intentsify topic id is Paused with a real weekly default schedule."