Provider Configuration Edge Cases on Topic-Intent Signals with the Clay CLI

A topic-intent signal's providerConfigs array selects intent data providers and their topics and tiers. Beyond the provider rules already documented, there is specific behavior for empty and null values, duplicate entries, repeated providers, and topic ids that exist in no catalog.

What you will build

CompanyTopicIntent signals that vary providerConfigs one way at a time, to record which forms are stored as given, which are rejected, and what each rejection says.

clay signals create --type CompanyTopicIntent --input '{"entityType":"ACCOUNT","segmentIds":[...],"providerConfigs":[<variant>]}'
    ↓
.signal.inputs.providerConfigs (as submitted)   |   validation_error (exit 2)

AI Prompt

Using the Clay CLI, probe `providerConfigs` handling on a CompanyTopicIntent signal.

Requirements:
- `providerConfigs` entries are `{"provider": "delivr"|"bombora"|"intentsify", "topicIds": [...]|null, "tiers": [...]|null}`.
- `tiers` accepts "low", "medium", "high" (lower case). Omitted, null, an empty array, and a
  repeated tier are all accepted and stored as submitted. "extreme" and "HIGH" are rejected.
- `topicIds` may be omitted, null, or an empty array. Duplicates are accepted. An empty string
  is rejected ("providerConfigs.0.topicIds.0: Required"). A number is rejected.
- A topic id that is in no catalog (for example "x") is accepted.
- An empty `providerConfigs` array returns "providerConfigs: Select at least one data provider".
  `providerConfigs: null` returns "--input: Invalid input".
- The same provider twice returns "providerConfigs.1.provider: Duplicate topic intent provider: delivr".
- An unknown provider returns "--input: Invalid input".
- bombora topic ids are topic names, matched by spelling; "sales intelligence" in lower case is
  accepted and stored as given.
- 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 companies segment (this doc uses audseg_0tm3nvu2EbBP6mjpk8f)

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. The probe shape

clay signals create --type CompanyTopicIntent --name "TPC19 intent" \
  --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3nvu2EbBP6mjpk8f"],"providerConfigs":[{"provider":"delivr","topicIds":["x"],"tiers":["high"]}]}'

Each result below is .signal.inputs.providerConfigs for one variant of that command.

2. Tiers

3. Topic ids

An id such as "x" is accepted because the CLI does not look ids up in a provider catalog. Ids come from clay signals search-topics.

4. The array itself and provider entries

Omitting providerConfigs entirely is a separate case: it stores a delivr config with all three tiers, as shown in the defaults doc in this batch.

Verify the result

Confirm a duplicate provider is rejected with a specific message:

clay signals create --type CompanyTopicIntent --name "TPC19 intent verify" --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3nvu2EbBP6mjpk8f"],"providerConfigs":[{"provider":"delivr","topicIds":["a"]},{"provider":"delivr","topicIds":["b"]}]}'; echo "exit $?"

Expected: stderr shows providerConfigs.1.provider: Duplicate topic intent provider: delivr and the command prints exit 2.

How it works

The provider and tier values are checked against fixed lists and the provider list is checked for emptiness and duplicates, which produce the path-bearing messages. Topic ids are validated only as non-empty strings, so a value in no provider catalog is stored and, per the CLI help, matches nothing when the signal runs. That was not observed here because no signal was activated.

Common issues

An invented topic id is accepted

"x" and a lower-cased bombora name both create successfully. Use ids returned by clay signals search-topics, and copy bombora names with their exact spelling.

An empty array and null mean different things at creation

providerConfigs: [] is an error, while an empty topicIds or tiers is accepted. The help text says an empty or missing topicIds means no topic filter, so the provider fires on any topic it tracks.

One provider per entry

Two entries for the same provider are rejected. Put all of a provider's topic ids in one entry.

Next steps

• See the existing doc on configuring two intent providers on one signal for the multi-provider case.
• See the existing doc on provider rules for what can change after creation.

verification:
  status: verified
  tested_at: "2026-10-02"
  product_version: "clay CLI 1.8.0+71cb1bf09c7e"
  command: "clay signals create --type CompanyTopicIntent --name \"TPC19 intent verify\" --input '{\"entityType\":\"ACCOUNT\",\"segmentIds\":[\"audseg_0tm3nvu2EbBP6mjpk8f\"],\"providerConfigs\":[{\"provider\":\"delivr\",\"topicIds\":[\"a\"]},{\"provider\":\"delivr\",\"topicIds\":[\"b\"]}]}'; echo \"exit $?\""
  expected_result: "stderr shows providerConfigs.1.provider: Duplicate topic intent provider: delivr and the command prints exit 2."

Related Articles

• How Topic-Intent Signals Are Billed with the Clay CLI
• Creating a Topic-Intent Signal with the Clay CLI
• Provider Rules on Topic-Intent Signals with the Clay CLI