Skip to main content

​
Troubleshooting: outbound campaign blocked at the pre-send gate chain

An outbound campaign that ships clean passes a short chain of pre-send checks before the first message or call goes out. When the chain finds something it reports a verdict instead of shipping: either the send is blocked outright (the pre-flight error codes name the gate class, so they show as GATE_BLOCKED-style refusals) or it ships with a warning (GATE_WARN-style advisories you acknowledge and proceed past). This page maps those verdicts back to the specific gate that fired and the tenant-owned fix for each. The gates themselves — their exact evaluation order, the specific error code each one returns, and which ones carry no opt-out — are the concept page Voice pre-send gate chain. This page is the runbook: it starts from the symptom (campaign will not launch, or launched with warnings) and ends at the control you own.

​
1. What pre-send screening does

Pre-send screening is a built-in chain of safety checks that runs on every outbound campaign before launch, and per recipient before the send goes out. A launch, a batch send, and a dialer campaign all take the chain; nothing ships until the chain evaluates. The chain stages, in the order they evaluate on the outbound voice path:
  1. Emergency short-code reject — platform-global, no toggle.
  2. TCPA federal dialing window for US voice, and your tenant opt-in quiet-hours gate for sent-hours you configured yourself.
  3. FCC AI-voice written-consent gate — synthetic or cloned voices need prior express written consent on record.
  4. Fraud-velocity guard and DNO caller-id reject — premium-rate prefixes, spend and rate caps, and Do-Not-Originate caller IDs.
  5. Trunk caller-id reject — the presented caller ID must sit in the trunk allow-list or your organization’s DID list.
  6. Per-country rate window — a sliding-window cap per destination country.
  7. STIR/SHAKEN attestation — resolved and stamped, never a blocking gate.
The full precedence table with per-gate error codes is on Voice pre-send gate chain. The launch-side result of this chain is what the campaign review step and, for orgs that require sign-off, the Outbound → Campaign approvals queue (/outbound/approvals) render as a blocked or warned launch. That queue exists for orgs whose campaign settings require supervisor approval before recipients are messaged — your supervisor (and an owner/admin) sees the same gate verdict there before approving.

​
2. Why a check hard-fails vs warns

Every verdict falls into one of two classes, and the class decides what you can do about it:
  • Blocked (GATE_BLOCKED class) — the hard fail. The send does not go out. Resolution is one of two shapes: fix the underlying condition the gate names (a caller ID that is not in the trunk allow-list, AI voice without written consent, a list aimed outside the federal window), or — for the gates that are tenant-owned — adjust or retract the tenant control that fired (your quiet-hours window, your per-country limits, your DNO override). Platform-owned gates at a statutory floor — the TCPA federal window, the FCC AI-voice consent gate, the BAA send gate, the emergency short-code reject — are hard-fail by design and carry no skip toggle. The page will not let a supervisor “approve past” a platform-owned block; the approval surface exists to sign off on tenant-owned gates, not to commute federal ones.
  • Warn (GATE_WARN class) — the advisory. The chain found a condition you should see before shipping — a policy-scan finding on your message body, a destination that historically converts poorly, a sender pool concentration. Warn-gated sends ship after you explicitly acknowledge the warning on the review step (or, for approval-required orgs, after a supervisor approves the launch in the approvals queue). A persistent warn on a gate you configured to warn-only is your own setting working as configured; a warn on a gate you configured to block moves into the blocked class above.
The distinguishing question is never “can I click past this” — it is who owns the gate. Codes or gates tied to the platform compliance floor fail hard and stay hard; tenant-owned controls carry the toggles, and the warn/block split on them comes from your own send-gates configuration. The per-gate ownership and fail-open vs fail-closed posture table is section 5 of Voice pre-send gate chain.

​
3. How the chain interacts with dedupe and the silent-unsubscriber sweep

Two stages of the chain are about who stays on the list, and they run as part of the same pre-send evaluation — so a blocked verdict on a list issue is often one of these, not a compliance gate. Retroactive dedupe. The chain de-duplicates the recipient list before any send goes out: case- and format-normalized numbers that appear twice (an uploaded list overlapping your own updated contacts, a re-imported CSV with stale rows) collapse to one attempt. The dedupe is retroactive in the sense that it applies to records you already ingested — a launch after an import uses the resolved recipient set, not the raw uploaded one. When the review step reports fewer recipients than your upload carried, the difference is largely this stage; it is a warn-class reduction you acknowledge, not a blocked verdict. Silent-unsubscriber sweep. Contacts that unsubscribed without a keyword reply — carrier-reported opt-outs, suppression-list additions, imported unsubscribe files — are swept by the same chain stage before any send. A send to such a contact is not merely warned; the contact is removed from the recipient set, and if the sweep empties the list the launch blocks with nothing addressable. The fix is list-side, and both the dedupe check and the sweep use the same suppression and consent stores as the consent and suppression model. A blocked verdict that survives fixing the compliance gates therefore usually means no recipient remains addressable after these two stages. Check the campaign’s resolved-recipient count on the review step before reworking your caller-ID or consent records. If you want the same chain stages spelled out per recipient before you launch, run a dialer preview — the preview claims walk the same per-recipient predicates the full campaign will (Troubleshooting: dialer preview, power, and predictive modes). The wizard-slide fallback for that preview (what each gate verdict means before you commit the full list) is the same runbook this page works.

​
4. Unblock the send — the decision path

Work these in order; every one moves a blocked verdict toward a launch, or resolves a warn to a clean pass.
  1. Read the verdict code on the review step (or the approvals queue). The pre-flight code names the gate class. Match it to the precedence table on Voice pre-send gate chain — the same code the API returns is the code the queue shows.
  2. If the code is a platform-owned gate, fix the underlying condition. Federal window — retime the send into 8 AM–9 PM recipient-local or shift recipients outside US ranges. FCC AI-voice consent — record prior express written consent before launch. DNO or trunk caller-ID — use a caller ID in the allow-list. There is no toggle; re-submit after the fix.
  3. If the gate is tenant-owned, adjust or retract your own control. Quiet-hours, per-country limits, DNO overrides, warn/block split — open the send-gates settings, change the toggle, and re-run the review; the verdict flips class on the next pre-send pass.
  4. If the sweep left no addressable recipients, re-import a clean list (dedupe collapses duplicates; suppression removals are terminal) and re-run the review.
  5. For approval-required orgs, have an owner/admin approve in Outbound → Campaign approvals after steps 1–4 pass; the queue rejects at the UI the same gates the API rejects, so approve only resolves tenant-owned warns and tenant-toggled blocks.

​
5. When to escalate

Escalate to support with:
  1. Your organization ID — Settings → Organization, or organizationId from GET /api/v1/me.
  2. The campaign ID, the mode (batch, dialer, drip), and the current status (draft, pending approval, active, aborted).
  3. The exact pre-send verdict — the blocked or warn code verbatim, and the resolved-recipient count from the review step (for dedupe / sweep verdicts).
  4. The gate you believe is tenant-owned vs platform-owned — if you disagree with the ownership split, that is a configuration question, not an outage.
A persistent platform block on a tenant-owned control only trips when the control genuinely fails closed — match the code first; the escalation only helps once the ownership question is settled.

​
See also