Scheduled Messages on Omdaa: Reminders & Drips Without Cron Sprawl

/dashboard/scheduled and APIs (schedule_message, cancel, list) queue future sends on a connected session — without hosting your own cron farm.

High-value uses

• Appointment reminders (24h / 2h).
• Consent-based abandoned-cart nudges.
• Onboarding drips (day 0/2/7) with cancel.
• Internal team pings at a fixed time.

Reliability

Own your timezone logic. Cancel when bookings change. Ensure the session will be connected at fire time. Use webhooks for delivery confirmation. Prefer Bulk+throttle for large simultaneous audiences.

Time modeling in your app

Store fire times in UTC; render local to users. On reschedule, cancel the old job before creating a new one. Tie booking cancellations to the same backend transaction as message cancel.

Drips need a state machine you own (signed up, profile complete, purchased). Scheduled is the executor, not the brain.

Monitoring

Scheduled UI + success/fail webhooks + daily due-queue report. A pile of “stuck” due messages usually means the session died first.

Common scheduling mistakes

Thousands of jobs at the same second stress the session — stagger. Forgetting cancel after booking cancel hurts trust. Local server clocks without UTC drift around DST. Write one test that schedules +1 minute then cancels early.

Frequently Asked Questions

Edit a scheduled message?

Typically cancel + recreate — check current API/UI.

Session down at fire time?

Send fails — monitor sessions and reschedule.

vs Bulk?

Scheduled = precise singles/drips; Bulk = large throttled slices.

Media supported?

Depends on scheduled payload support — test in staging.

Start free: Create account · Dashboard · Docs