> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hubtalk.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Consent, the registry and who is responsible

> Consent attestation, the do-not-call registry, and what the platform does itself.

# Consent, the registry and who is responsible

## Consent attestation and the purpose of the campaign

Before launch the platform requires you to attest that you have the subscribers' consent to be called. In the dashboard this is a checkbox with legal text; through the API it is the `attestation` field in the request. Without it the campaign is still created, but stays a draft with the reason "a signature is required".

The signature is placed by the **key**, and the human link is the employee who issued the key ([The access key](/v4/web-api/start)). The signature is tied to a specific version of the data: an attestation given for one list of numbers does not carry over to the next one. Upload a new list or add a batch of numbers and you attest again.

**The purpose of the campaign** (`classification`) — what exactly you are calling about:

| Value             | What it covers                                | Consent tier                                           |
| ----------------- | --------------------------------------------- | ------------------------------------------------------ |
| `marketing`       | offers, advertising, surveys                  | `pewc` — prior express written consent (the strictest) |
| `servicing`       | servicing: reminders, notifications, statuses | `pec` — prior express consent                          |
| `debt_collection` | debt collection                               | `pec` — prior express consent                          |

The purpose determines the **consent tier** (`consent_tier`) — which legal text you actually sign. That is why the platform does not guess it: if you do not specify it, `marketing` is used, the strictest option. The response returns both the purpose and the resulting tier, so you can see which text you signed.

## The do-not-call registry

The platform finds numbers from your organization's registry **before** the first call and lists them one by one. Every readable row of the list is screened before duplicates are removed: three rows carrying the same number are therefore three matched rows but one excluded number. Rows whose phone could not be read count as "not screened", and a clean result is always returned as an explicit `clean` status rather than left to be inferred from an empty list. The launch stops at that point.

What happens next is your decision:

* **keep the block** (`dnc: "block"`, the default) — the matched numbers are not dialed;
* **confirm the campaign** (`dnc: "skip"`) — the platform records this decision in the audit log exactly as it records the button in the dashboard, noting which upload **and which exact composition of matches** it applies to. A new registry record against the same list resets the confirmation, and the launch check shows the refreshed list of matches.

If **all** dialable numbers turned out to be in the registry, there is nothing to confirm — the launch stops unconditionally. Immediately before the launch the platform reads the live registry again and stores its snapshot together with the signature; after the launch the campaign card and the match report show exactly that snapshot, even if the registry changes later. Numbers that land in the registry while the campaign is already running are still not dialed — the campaign progress counts them separately.

<Warning>
  For batches of numbers added to an existing campaign ([Consent and responsibility](/v4/web-api/rules)) the rule is harsher: a registry match does not "stop the launch" but **refuses the whole batch** — you cannot confirm calling such numbers through the add-calls path.
</Warning>

## What the platform does itself and what stays with you

**The platform does:** number and variable parsing, duplicates, the do-not-call registry, geography and the legal calling window (US), the organization's calling window, dialing pace, no-answer retries, per-number frequency caps, contact time zones, call recordings, result parsing.

**You keep:** deciding when to launch a campaign and with which list; storing the link between your own entities and the campaign; reading progress if you need a status in your interface; receiving call results ([webhooks](/v4/webhooks) per call work the same as for individual calls).

**About no-answer retries.** By default a campaign makes **one attempt** per number and calls nobody back. If you want the platform to retry by itself, set the number of attempts and the pause between them (`retry_config`). If your own system manages the redials — it sends the number again as its own retry — leave one attempt: otherwise the redial becomes two-level, yours plus the platform's. A number sent again that the campaign has already dialed is accepted as a new call and dialed again.

**About working hours.** If you did not give the campaign working hours, that does not mean "dial round the clock": the platform dials within your organization's calling window (and in the US — within the legal window of the subscriber's jurisdiction). A campaign's hours may only **narrow** that window; an attempt to set wider hours is refused immediately.

**Adding numbers to a campaign that already exists** — possible, with a separate request (`POST /v1/campaigns/{id}/calls`): the batch carries the numbers and the signature, while the agent, the line, the working hours and the retries come from the campaign. It works for any campaign that is not closed — a draft, a scheduled, a running or a paused one. Rules worth knowing in advance:

* **a batch is accepted whole or refused whole.** One unreadable row and not a single number from the batch is dialed (`calls_rejected`); one number from the do-not-call registry and the batch is refused as well, but with its own code (`calls_dnc_matched`), so your system can tell "fix the data" from "remove these people from your base". The answer carries the parse of the refused batch with the upload number and the first rows; the full report is fetched as for any upload;
* **a batch is accepted even when the campaign is not dialing right now** — while it is paused, for instance. The answer says the numbers were accepted and names the reason for the standstill (`campaign_paused`); dialing continues after a resume;
* **an ordinary campaign closes itself when the queue drains** — and after that it accepts no numbers at all. For a campaign that is meant to wait for numbers, create it **open to call additions**: `accepts_call_additions: true` with a mandatory end date, no more than 30 days out. Such a campaign may be created empty, filled with batches, and closed either by cancelling it or by letting its end date arrive. The flag is set at creation and cannot be changed;
* **no more than 1000 numbers per batch** — split larger ones.

**Deliberately not provided** — do not look for these capabilities, they do not exist:

* **a separate "campaign finished" event.** State is read with a progress request or from the campaign card;
* **a separate campaign results endpoint with transcripts.** Results are read as ordinary calls;
* **different permissions for different keys.** A key either exists or it does not; restricting access per area is not provided.