Six steps between receiving a message and sending one back. The AI reads the full conversation, decides what to say, and decides when to end. The code doesn't second-guess it.
Inbound webhooks validate, enqueue, and return 200 OK immediately. The pipeline runs asynchronously — so burst traffic from a large campaign doesn't stack up behind slow AI calls.
Opt-outs, time windows, and frequency limits are enforced in code — not left to the AI's judgment. The AI never receives a message that compliance has already handled.
Hard opt-out keywords — STOP, UNSUBSCRIBE, CANCEL, and common variants — are matched using word-boundary-aware logic to avoid false positives on words like "stopping by".
Opt-out keyword scan — STOP, UNSUBSCRIBE, CANCEL + variants
Contact opt-out flag — permanent record checked before every message
7-day silence window — closes conversations with no activity
30-day messaging window — blocks non-opt-out messages after expiry
Frequency cap — bump intervals enforced per campaign config
Audit row — every check logged with outcome and timestamp
Bump intervals are configured per campaign as an array of minimum hours between touches. The scheduler derives the maximum number of bumps from the array length — no separate cap to manage.
Each campaign defines its own bump_intervals array — for example [24, 48, 96] means bump after 1 day, then 2 days, then 4 days. The platform enforces minimum hours between each touch.
How it works: How it works: max_bumps is derived from array length. A 3-item array means 3 bumps maximum — no separate field to keep in sync.
Bumps only fire within configured business hours and timezone. The scheduler checks eligibility before enqueuing — contacts are never messaged at 2am because a job happened to run then.
How it works: Timezone-aware: multi-segment hour strings supported. Configure different windows for weekdays and weekends per campaign.
All scheduler eligibility queries use FOR UPDATE SKIP LOCKED — multiple workers can run simultaneously without processing the same conversation twice, even under heavy load.
How it works: Queue-backed: Redis + RQ absorbs burst traffic. Worker restarts don't lose queued jobs — all state is persisted in PostgreSQL.
If an outbound send fails, the platform retries at 60 seconds, then 300 seconds. After three failed attempts, the turn is flagged for operator review — no silent failures.
How it works: Idempotent by design: MessageSid is checked before every send. A recovered worker can never send the same message twice.
One campaign. One contact list. We'll have you sending in days, not weeks.