Audience name.

Description of the audience.

Audience type. contact builds the audience by filtering the contact database; elixir is the former name for contact and is still accepted, so existing integrations do not need to change. Setting source_list_id treats the audience as type list regardless of the value sent here. See source_list_id, source_list_mode, and source_list_path below for list-sourced audiences.

Segmentation type.

How to build the audience population from the list referenced by source_list_id. Required when source_list_id is set.

• values: use the list's raw values as-is, including any values that are not found in our contact database.
• matched: match each list value against our contact database and expand matched people to their full set of hashed emails and other identifiers. Every list value is kept in the audience; unmatched values are never dropped.

The materialized data file path for the list referenced by source_list_id, supplied by the list itself (see file_path on the list object in the Lists & Campaigns reference). Pass through the value provided by the list rather than constructing it yourself.

Column projection for the unload output, applied as a SQL SELECT clause. Defaults to *, which emits the full field-catalog schema (contact and firmographic fields alongside hem, profile_pid_all, perc_score, and ts). Set a comma-separated column list to narrow the output, for example hem,linkedin_url,current_business_email.

preview to get a size estimate, unload to write output files. Defaults to preview.

This matters if you intend to download the audience. A preview audience is built count-only, so the first download has to rebuild it at full width before it can serve data. Passing unload at create time builds it once, correctly, and avoids that second build.

There is no unload field on the update endpoint, so switching an existing preview audience to unload means creating a new audience.

Schedule for automatic refresh.

• daily: refreshes every day at 09:00 UTC.
• weekly: refreshes every Saturday at 18:00 UTC (weekend afternoon UTC, so the weekly batch doesn't compete with daily intent refreshes at 09:00 UTC).
• manual: no automatic refresh; the audience only refreshes when a caller hits POST /audiences/{id}/refresh or re-runs an unload manually.

When omitted, the default depends on type:

• intents: defaults to daily (intent data is produced fresh every day).

• contact (and its former name elixir): defaults to weekly (contact source data refreshes weekly/monthly; daily renewal would re-run unloads against unchanged data). Both spellings name the same type and get the same default.

• list: defaults to weekly. A list changes only when you edit it, not on the daily intent cadence.

Customers who really want daily refresh on a contact audience can opt in by passing daily explicitly.

What one output row should represent. Only applicable to intents audiences.

• person_topic: one row per person per topic, keeping every topic a person matched.
• person: one row per person, keeping their highest-scoring topic only.

When omitted, the grain is derived from the date range for backwards compatibility: a 1-day window or a pinned range yields person_topic, a multi-day window yields person. That derivation is why widening a window used to change the row shape. Set this explicitly if the shape matters to you, and read row_grain on the audience to confirm what you got.

Start of a fixed historical date range to build over (YYYYMMDD, inclusive).

Must be supplied together with intent_end_date, cannot be combined with intent_window_days, and the range may span at most 14 days. Every day in the range must have intent data available: a partially available range is rejected and the response names the missing days, rather than quietly building over the days that happen to be present.

Use this to backfill specific past days. intent_window_days is always relative to the most recent day of intent data we hold, so it cannot reach a particular date, and narrowing it to 1 still returns the latest day rather than the day you are missing.

End of the fixed historical date range (YYYYMMDD, inclusive). Required when intent_start_date is set. See intent_start_date.

Initial status.