Which NewHire Filter Keys Validate Their Values with the Clay CLI

The filters object on a NewHire signal has more than forty keys. The CLI checks some of them strictly, checks others only for type or range, and accepts any string in the rest. Grouping the keys by that behavior shows which mistakes fail at creation and which are stored and left for run time.

What you will build

A table, built from signals create runs, that sorts the NewHire filter keys into three groups: values checked against a list, values checked for type or range, and values not checked at all.

clay signals create --type NewHire --input '{...,"filters":{"<key>":<value>}}'
    ↓
exit 0 (stored) | exit 2 (rejected)    for each key, with one valid and one invalid value

AI Prompt

Using the Clay CLI, determine which NewHire filter keys validate their values.

Requirements:
- Use `"start_from_method":"query"` in every filters object.
- Keys checked against a closed list reject any other value: `job_title_seniority_levels_v2`,
  `job_title_seniority_match_mode`, `job_title_seniority_floor_level`, `job_title_mode`,
  `company_sizes`, `company_annual_revenues`.
- Keys checked for type or range: `include_past_experiences` (boolean), `limit` (>= 1),
  `limit_per_company` (1 to 100), `current_role_min_months_since_start_date` (>= 0).
- Free-text keys accept any string: locations and exclusions, industries, descriptions,
  keywords, school names, languages, certifications, names, and `job_functions`.
- The documented range for `limit` is 1 to 10000, but 10001, 100000, and 1.5 were accepted.
- An inverted pair (`current_role_min_months_since_start_date` greater than `..._max_...`) is accepted.
- Unknown keys are dropped.
- 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

Each row below was one signals create call of this shape, with only filters changed:

clay signals create --type NewHire --name "TPC19 newhire" --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3nvu2EbBP6mjpk8f"],"filters":{"start_from_method":"query","limit":10001}}'

2. Keys checked against a list

All rejections are exit 2 with --input: Invalid input.

3. Keys checked for type or range

The CLI help documents limit as a number from 1 to 10000. Values above 10000 were accepted, so the upper bound is not enforced at creation.

4. Keys not checked

These were accepted with any value tried, and stored as given:

{"start_from_method":"query","company_industries_include":["Definitely Not An Industry"]}
{"start_from_method":"query","job_functions":["Sales"]}
{"start_from_method":"query","locations":["United States","Canada"],"locations_exclude":["California"]}
{"start_from_method":"query","languages":["Spanish"],"certification_keywords":["PMP"],"school_names":["Stanford University"]}
{"start_from_method":"query","profile_keywords":["kubernetes"],"headline_keywords":["founder"],"about_keywords":["open source"]}
{"start_from_method":"query","names":["Jane Doe"]}
{"start_from_method":"query","company_description_keywords":["observability"]}
{"start_from_method":"query","job_title_exclude_keywords":["intern","assistant"],"job_title_keywords":["sales"]}

An unknown key ("net_worth":"high") was accepted and dropped: the stored filters held only start_from_method.

Verify the result

Confirm the documented upper bound on limit is not enforced:

clay signals create --type NewHire --name "TPC19 limit verify" --input '{"entityType":"ACCOUNT","segmentIds":["audseg_0tm3nvu2EbBP6mjpk8f"],"filters":{"start_from_method":"query","limit":10001}}' | jq -c '.signal.inputs.filters.limit'

Expected: the output is 10001.

How it works

Enumerated keys are validated against their lists, booleans against their type, and numeric keys against a lower bound, with a few upper bounds. Free-text keys are plain string arrays. The help text's limit range of 1 to 10000 does not match what the create call enforces, which is a lower bound of 1 only. The response never names the key that failed an enumerated check, so the table above is the quickest way to find which key a rejection came from.

Common issues

A value accepted at creation is not proof it is valid

The free-text keys cannot fail on content. A typo in a location, industry, or job function is stored, and any effect would show up only when the signal runs.

limit above 10000 and fractional limits are accepted

If a cost cap matters, validate the number in the calling script. The CLI enforces only a minimum of 1.

Rejections do not name the key

--input: Invalid input appears for the enumerated and boolean keys. Only the numeric range failures include a path such as filters.limit.

Next steps

• See the seniority and company-size docs in this batch for the valid values of the enumerated keys.
• See the existing doc on controlling signal spend through filters for how limit and limit_per_company bound cost.

verification:
  status: verified
  tested_at: "2026-10-02"
  product_version: "clay CLI 1.8.0+71cb1bf09c7e"
  command: "clay signals create --type NewHire --name \"TPC19 limit verify\" --input '{\"entityType\":\"ACCOUNT\",\"segmentIds\":[\"audseg_0tm3nvu2EbBP6mjpk8f\"],\"filters\":{\"start_from_method\":\"query\",\"limit\":10001}}' | jq -c '.signal.inputs.filters.limit'"
  expected_result: "The output is 10001."

Related Articles

• Watching Companies for Matching Job Postings with the Clay CLI
• Narrowing a Job Posting Signal by Posting Age and Type with the Clay CLI
• What the Server Adds to a Signal's Inputs, Per Type, with the Clay CLI