The pre-dial gate

India regulates who may be called, about what, and when. TCCCPR liability sits with the sender — you — and there is no statutory safe harbour for using a vendor. What Tone can do is run the checks and keep the evidence that you ran them.

What runs, in order

Every dial — direct, campaign, or BYO — runs all six, inside the same transaction as the call record.

Calls placed before 6 October 2026 carry a carrier_dnd row in place of dnd_register: the carrier's metadata, which only ever warned.

The DND register check

DND preferences govern promotional calls only. For a transactional or service call the check passes as not_applicable, and the number is never sent anywhere.

For a promotional call, Tone looks the number up through a third-party DND lookup. Its rows carry source: "vendor", because the answer is the vendor's list, not the register itself.

• Listed: the call is refused (blocked_dnd), unless an explicit consent for that number and purpose is on record. Consent overrides a DND preference.
• The lookup can't answer (unavailable, out of credit): the call goes ahead and the row records a warning saying so.
• A promotional campaign has its whole list checked at launch. Listed numbers are excluded and counted under dnd_scrub, and each dial reuses the launch answer for 24 hours instead of looking the number up again.

Each writes a row with an outcome of pass, warn or block, whatever it decided. The table is append-only at the database level: nothing can edit or delete a check after the fact, which is the entire point of having one.

curl -H "Authorization: Bearer $TONE_KEY" \
  "$TONE_API/v1/compliance/checks?e164=%2B919876543210&outcome=block"

The A2P pre-declaration

TCCCPR regulation 4 requires notifying your Originating Access Provider, in writing and in advance, that auto-dialer / robo-call technology is in use. File the declaration with your access provider, then record its reference under Compliance → Auto-dialer pre-declaration — the a2p check warns on every promotional call placed without one, and each evidence record cites the declaration when it exists.

For now the check applies to promotional calls only. Transactional, service and collections calls record it as not_applicable, and it never flags them.

What the DND check is, and is not

India's DND register is deliberately not exposed to telemarketers — that is its design, not an oversight. Tone reads it through a third-party lookup, and every answer is recorded with source: "vendor", so the evidence says whose answer it was.

🔴 Tone does not claim authoritative NCPR scrubbing, and you should not either. What always blocks is your own suppression list. The DND register check adds the vendor's answer for promotional calls, labelled as the vendor's: a promotional call to someone on DND needs their explicit consent on record.

Calling windows

Narrowed from the industry default of 08:00 because we cannot read an individual recipient's registered preference band, so the safe assumption is the tightest one.

There is no override, and no request field reaches the gate. A caller who could opt out of being checked would make every audit row meaningless.

Where purpose comes from

From durable configured state, never from the request:

• A Tone agent supplies its own purpose.
• A BYO number has no agent, so the organization's declared sender classification is used. Set it in the dashboard under Telephony → Compliance → Sender classification; dialling before declaring one is a 422.

Checking without dialling

If you dial on your own carrier, ask for the verdict directly. It writes the same audit rows a dial writes, and answers 200 either way — a refusal is a verdict, not an error.

curl "$TONE_API/v1/compliance/check" -X POST \
  -H "Authorization: Bearer $TONE_KEY" -H 'content-type: application/json' \
  -d '{"e164":"+919876543210","purpose":"promotional"}'

See Compliance as an API.

When a call is blocked

403, with error.code naming which check stopped it:

error.details carries checkType and reason, and the audit row is already written — so a block is fully explainable after the fact from GET /v1/compliance/evidence.

Sealed evidence records

Beyond the raw audit rows, every call attempt — completed calls and refused dials — produces one sealed evidence record: the legal basis to call (your DNC result, the consent record relied on, the DND register result), how the call was placed (DLT registration, A2P declaration, calling window, the number's status at dial time, whether the AI disclosure was spoken and when), and the outcome.

Each record carries a sha256 of its canonical content plus the previous record's hash, forming a per-organisation chain: editing any record breaks its own hash, and deleting or reordering one breaks every later link.

# the record for one call, or the same as a PDF at /evidence.pdf
curl -H "Authorization: Bearer $TONE_KEY" \
  "$TONE_API/v1/calls/{id}/evidence"

# prove the chain's integrity, on demand
curl -H "Authorization: Bearer $TONE_KEY" \
  "$TONE_API/v1/compliance/evidence-records/verify"

The PDF at /v1/calls/{id}/evidence.pdf reads the same record for a person: a verdict, a timeline of what happened when (checks run, call connected, AI disclosure played, call ended, record sealed, in IST to the second), what each check found, and the seal with its hashes. Everything on it comes from the sealed content.

The table is append-only at the database level, and its rows survive even an organisation deletion. Records seal shortly after a call ends; a refused dial seals in the same transaction as its refusal.