Provider Rules on Topic-Intent Signals with the Clay CLI

A topic-intent signal's provider list is fixed the moment it is created, and bombora validates on a person-scoped signal without ever actually being used. Both behaviors matter before choosing a provider mix, because neither is reversible or visible after the fact without re-reading the signal.

What you will build

A PersonTopicIntent signal created with a bombora config (which bombora does not support for person-level intent), plus an update attempt that tries to add a new provider to an existing signal.

clay signals create --type PersonTopicIntent --input '{...bombora config...}'
    ↓
clay signals update <triggerDefinitionId> --input '{...add a provider...}'   → validation_error

AI Prompt

Using the Clay CLI, demonstrate two real constraints on topic-intent signal providers.

Requirements:
- Person topic intent supports only delivr and intentsify. A bombora providerConfig on a
  PersonTopicIntent signal validates and is created successfully, but is ignored at run
  time; a signal left with no supported provider configured runs on the default (delivr,
  all tiers) instead.
- The set of providers on a signal is fixed at creation. `clay signals update` can change
  an existing provider's topicIds and tiers, but adding or removing a provider entry
  returns a validation_error, because each provider carries its own detection baseline.
- 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 Audiences segment for the people entity type

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. Create a PersonTopicIntent signal with a bombora config

clay signals create --type PersonTopicIntent \
  --name "Person intent, bombora config" \
  --input '{"entityType":"CONTACT","segmentIds":["audseg_example"],"providerConfigs":[{"provider":"bombora","topicIds":["Sales Intelligence"]}]}'

Real output:

{
  "id": "td_example",
  "runStatus": "Paused",
  "signal": {
    "type": "PersonTopicIntent",
    "inputs": {
      "providerConfigs": [{ "provider": "bombora", "topicIds": ["Sales Intelligence"] }],
      "entityType": "CONTACT",
      "segmentIds": ["audseg_example"]
    }
  }
}

The command succeeds and stores the config exactly as submitted. Nothing in the response indicates that bombora will not actually be checked for a person-scoped signal.

2. Attempt to add a provider to an existing signal

clay signals update td_other_example --input '{"providerConfigs":[{"provider":"intentsify","topicIds":["48702"],"tiers":["high"]},{"provider":"bombora","topicIds":["Sales Intelligence"]},{"provider":"delivr","topicIds":null}]}'

Real output:

{
  "error": {
    "code": "validation_error",
    "message": "Topic intent providers cannot be changed after creation"
  }
}

Verify the result

clay signals update <triggerDefinitionId> --input '{"providerConfigs":[{"provider":"<a provider not already on the signal>","topicIds":null}]}'

Expected: a validation_error with the message "Topic intent providers cannot be changed after creation", on any existing topic-intent signal.

How it works

Each intent provider carries its own detection baseline, so the API treats the provider set as part of the signal's identity rather than an editable field. providerConfigs in an update call may only touch topicIds and tiers on providers already present. bombora is validated structurally the same way on any topic-intent signal, whether or not that signal's entity type actually supports it, and the mismatch only surfaces as silent inactivity at run time, not as a creation-time error.

Common issues

A bombora config on a person-scoped signal creates successfully and does nothing

PersonTopicIntent only supports delivr and intentsify. A bombora entry in providerConfigs passes validation and is stored, but is not checked when the signal runs. If every configured provider is unsupported this way, the signal falls back to the type's default (delivr, all tiers, no topic filter) rather than failing or running with zero providers.

Changing providers requires a new signal

Because provider identity is fixed at creation, switching from intentsify to bombora, or adding a second provider to a signal created with one, is not possible through clay signals update. Create a new signal with the intended provider set instead.

Next steps

• How Topic-Intent Signals Are Billed
• Resolving Topic Ids by Plain-Language Query

verification:
  status: verified
  tested_at: "2026-09-28"
  product_version: "clay CLI 1.4.0"
  command: "clay signals update <triggerDefinitionId> --input '{\"providerConfigs\":[{\"provider\":\"<new provider>\",\"topicIds\":null}]}'"
  expected_result: "Returns validation_error: Topic intent providers cannot be changed after creation."

Related Articles

• How Topic-Intent Signals Are Billed with the Clay CLI
• Creating a Topic-Intent Signal with the Clay CLI
• Configuring Two Intent Providers on One Signal with the Clay CLI