Which Signal Types Accept Which Audience Entity Types with the Clay CLI

An audience signal's entityType is CONTACT (people) or ACCOUNT (companies). Only the two topic-intent types enforce a fixed value; the other five accept either one as long as the segment is of the matching kind. A full matrix of the fourteen type and entity combinations shows exactly where the CLI stops a mismatch.

What you will build

A loop that creates one Paused signal for every combination of the seven signal types and the two entity types, using a segment of the matching kind, and prints the outcome of each.

for type in 7 types, for entityType in ACCOUNT CONTACT:
    clay signals create --type <type> --input {entityType, segmentIds:[matching segment]}
    ↓
ok id=td_...   |   validation_error: a <Type> signal watches <KIND> records, so entityType must be <KIND>

AI Prompt

Using the Clay CLI, determine which signal types accept which audience entity types.

Requirements:
- Run `clay signals create --type <T> --input '{"entityType":"<E>","segmentIds":["<seg>"]}'` for
  each of the seven types and both entity types, using an ACCOUNT segment for ACCOUNT and a
  CONTACT segment for CONTACT, so the segment kind never causes the failure.
- PersonTopicIntent accepts only CONTACT, and CompanyTopicIntent accepts only ACCOUNT. The other
  mismatch returns validation_error (exit 2) with a specific message.
- JobChange, Promotion, NewHire, JobPost, and News accepted both entity types.
- A segment of one kind with the other kind's entityType is rejected separately, with the message
  "Audience segment <id> is a <KIND> segment, not <OTHER>".
- Run the verification step below before finishing.

Using the Clay CLI, determine which signal types accept which audience entity types.

Requirements:
- Run `clay signals create --type <T> --input '{"entityType":"<E>","segmentIds":["<seg>"]}'` for
  each of the seven types and both entity types, using an ACCOUNT segment for ACCOUNT and a
  CONTACT segment for CONTACT, so the segment kind never causes the failure.
- PersonTopicIntent accepts only CONTACT, and CompanyTopicIntent accepts only ACCOUNT. The other
  mismatch returns validation_error (exit 2) with a specific message.
- JobChange, Promotion, NewHire, JobPost, and News accepted both entity types.
- A segment of one kind with the other kind's entityType is rejected separately, with the message
  "Audience segment <id> is a <KIND> segment, not <OTHER>".
- 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)
A people segment (audseg_0tm3lyrDBZzZgPaCsWx) and a companies segment (audseg_0tm3nvu2EbBP6mjpk8f)
jq and bash

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. Every signal created here is Paused.

1. Run the matrix

for t in JobChange Promotion NewHire JobPost News PersonTopicIntent CompanyTopicIntent; do
  for

for t in JobChange Promotion NewHire JobPost News PersonTopicIntent CompanyTopicIntent; do
  for e in ACCOUNT CONTACT; do
    seg=audseg_0tm3nvu2EbBP6mjpk8f; [ $e = CONTACT ] && seg=audseg_0tm3lyrDBZzZgPaCsWx
    out=$(clay signals create --type $t --name "TPC19 matrix $t $e" --input "{\"entityType\":\"$e\",\"segmentIds\":[\"$seg\"]}" 2>&1); ec=$?
    echo "$t | $e | exit $ec | $(echo "$out" | jq -rc 'if .error then .error.message else "ok id="+.id end')"
  done
done

Real output:

JobChange | ACCOUNT | exit 0 | ok id=td_0tmb2hz686EgkznQWYb
JobChange | CONTACT | exit 0 | ok id=td_0tmb2i0EmYM3BR4siWc
Promotion | ACCOUNT | exit 0 | ok id=td_0tmb2i1z5mJovehSdKh
Promotion | CONTACT | exit 0 | ok id=td_0tmb2i25mXDuwkVjsmN
NewHire | ACCOUNT | exit 0 | ok id=td_0tmb2i3vEwvGSYNKUEE
NewHire | CONTACT | exit 0 | ok id=td_0tmb2i4SzVUg6xy6muB
JobPost | ACCOUNT | exit 0 | ok id=td_0tmb2i5fSzrkqbNUhvB
JobPost | CONTACT | exit 0 | ok id=td_0tmb2i6e4Pvajprb2uV
News | ACCOUNT | exit 0 | ok id=td_0tmb2i8k2RZGmtsnfoS
News | CONTACT | exit 0 | ok id=td_0tmb2i8sa98VKa8Xzxn
PersonTopicIntent | ACCOUNT | exit 2 | --input: a PersonTopicIntent signal watches CONTACT records, so entityType must be CONTACT, not ACCOUNT
PersonTopicIntent | CONTACT | exit 0 | ok id=td_0tmb2i9veRuKC4nWqPu
CompanyTopicIntent | ACCOUNT | exit 0 | ok id=td_0tmb2iavnspJu5UDZgc
CompanyTopicIntent | CONTACT | exit 2 | --input: a CompanyTopicIntent signal watches ACCOUNT records, so entityType must be ACCOUNT, not CONTACT

JobChange | ACCOUNT | exit 0 | ok id=td_0tmb2hz686EgkznQWYb
JobChange | CONTACT | exit 0 | ok id=td_0tmb2i0EmYM3BR4siWc
Promotion | ACCOUNT | exit 0 | ok id=td_0tmb2i1z5mJovehSdKh
Promotion | CONTACT | exit 0 | ok id=td_0tmb2i25mXDuwkVjsmN
NewHire | ACCOUNT | exit 0 | ok id=td_0tmb2i3vEwvGSYNKUEE
NewHire | CONTACT | exit 0 | ok id=td_0tmb2i4SzVUg6xy6muB
JobPost | ACCOUNT | exit 0 | ok id=td_0tmb2i5fSzrkqbNUhvB
JobPost | CONTACT | exit 0 | ok id=td_0tmb2i6e4Pvajprb2uV
News | ACCOUNT | exit 0 | ok id=td_0tmb2i8k2RZGmtsnfoS
News | CONTACT | exit 0 | ok id=td_0tmb2i8sa98VKa8Xzxn
PersonTopicIntent | ACCOUNT | exit 2 | --input: a PersonTopicIntent signal watches CONTACT records, so entityType must be CONTACT, not ACCOUNT
PersonTopicIntent | CONTACT | exit 0 | ok id=td_0tmb2i9veRuKC4nWqPu
CompanyTopicIntent | ACCOUNT | exit 0 | ok id=td_0tmb2iavnspJu5UDZgc
CompanyTopicIntent | CONTACT | exit 2 | --input: a CompanyTopicIntent signal watches ACCOUNT records, so entityType must be ACCOUNT, not CONTACT

2. The matrix as a table

Type	ACCOUNT	CONTACT
JobChange	accepted	accepted
Promotion	accepted	accepted
NewHire	accepted	accepted
JobPost	accepted	accepted
News	accepted	accepted
PersonTopicIntent	rejected (exit 2)	accepted
CompanyTopicIntent	accepted	rejected (exit 2)

3. The segment kind is checked separately

clay signals create --type JobChange --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3lyrDBZzZgPaCsWx"]}'
clay signals create

clay signals create --type JobChange --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3lyrDBZzZgPaCsWx"]}'
clay signals create --type JobChange --input '{"entityType":"CONTACT","segmentIds":["audseg_0tm3lyrDBZzZgPaCsWx","audseg_0tm3nvu2EbBP6mjpk8f"]}'

Real errors (both exit 2):

{"error":{"code":"validation_error","message":"Audience segment audseg_0tm3lyrDBZzZgPaCsWx is a CONTACT segment, not ACCOUNT"}}
{"error":{"code":"validation_error","message"

{"error":{"code":"validation_error","message":"Audience segment audseg_0tm3lyrDBZzZgPaCsWx is a CONTACT segment, not ACCOUNT"}}
{"error":{"code":"validation_error","message":"Audience segment audseg_0tm3nvu2EbBP6mjpk8f is a ACCOUNT segment, not CONTACT"}}

The second command shows that one wrong-kind segment in a list of otherwise valid ids rejects the whole create.

Verify the result

Confirm the two enforced rejections:

clay signals create --type PersonTopicIntent --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3nvu2EbBP6mjpk8f"]}'; echo "exit $?"

clay signals create --type PersonTopicIntent --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3nvu2EbBP6mjpk8f"]}'; echo "exit $?"

Expected: stderr shows a PersonTopicIntent signal watches CONTACT records, so entityType must be CONTACT, not ACCOUNT and the command prints exit 2.

How it works

The topic-intent types name the record population they read (people for person intent, companies for company intent), and the CLI checks entityType against it before looking at the segment. The other five types are checked only for the segment's kind matching entityType. The CLI's per-type help lists a single entityType for each of those five (CONTACT for JobChange and Promotion, ACCOUNT for NewHire, JobPost, and News), but both values were accepted when the segment matched.

Common issues

Accepted does not mean meaningful

A JobChange signal on an ACCOUNT segment is created without an error. The help describes JobChange as watching people, so the signal's behavior on company records was not observed here, because none was activated. Prefer the entity type the help lists for each type.

The wrong-kind error has a grammar slip and an id

The message reads is a ACCOUNT segment, not CONTACT and names the segment id. Use the id to look the segment up with clay audiences get.

One bad segment fails the whole create

A list with a valid and an invalid segment creates nothing. Fix the list and re-run.

Next steps

See the segment-id doc in this batch for what else segmentIds accepts.
See the existing signal targeting edge-cases doc for the "ALL" sentinel.

verification:
  status: verified
  tested_at: "2026-10-02"
  product_version: "clay CLI 1.8.0+71cb1bf09c7e"
  command: "clay signals create --type PersonTopicIntent --input '{

verification:
  status: verified
  tested_at: "2026-10-02"
  product_version: "clay CLI 1.8.0+71cb1bf09c7e"
  command: "clay signals create --type PersonTopicIntent --input '{\"entityType\":\"ACCOUNT\",\"segmentIds\":[\"audseg_0tm3nvu2EbBP6mjpk8f\"]}'; echo \"exit $?\""
  expected_result: "stderr shows that a PersonTopicIntent signal watches CONTACT records so entityType must be CONTACT, and the command prints exit 2."