Plans & Limits
SendItWhenever has flat, predictable pricing. You're billed by the number of schedules you create per month — not by how many are active at once, and never per-message at fire time.
What each plan includes
| Free | Indie — $19/mo | |
|---|---|---|
| Schedules / month | 2,000 | 50,000 |
| Max payload size | 50 KB | 256 KB |
| Delivery rate | 20 / second | 500 / second |
| Max scheduling window | 30 days | 180 days |
Max batch size (bulk) |
100 | 500 |
| Max retry attempts | 5 | 10 |
| Attempt-log retention | 7 days | 30 days |
Annual billing is two months free — Indie $190/yr.
Founding price: the first 50 Indie customers get one month free, then $15/mo locked for the life of the subscription — they never pay the $19 list price.
Higher-volume Studio and Scale tiers (more monthly schedules, larger payloads, faster delivery) are on the roadmap and open after launch.
- Schedules / month is the billing unit: every schedule you create counts once, in the calendar month (UTC) it's created. Firing, cancelling, or replaying never re-counts an existing schedule — only fresh
POSTs do. - Delivery rate is how fast queued schedules are dispatched at peak. Exceeding it throttles dispatch in order; nothing is dropped.
- Max scheduling window caps how far into the future
fireAtcan be (encrypted payloads live in the delayed queue until they fire, so the window bounds storage cost). - Max batch size is the most schedules a single
POST /v1/schedules/bulkcall may create.
Upgrade or manage your subscription from the billing settings. Payments are handled by Lemon Squeezy as Merchant of Record.
What happens when you hit a limit
Limits fail loudly and specifically, so you can handle them in code:
| Situation | Result |
|---|---|
| You've used your full monthly schedule quota (plus the 10% grace) and try to create another | 403 FORBIDDEN |
| You're within the last 10% grace over your monthly quota | Allowed — the response carries an over_limit flag prompting an upgrade. Nothing is blocked yet. |
fireAt is further out than your plan's scheduling window |
400 VALIDATION |
A bulk call exceeds your plan's max batch size |
400 VALIDATION |
| Payload exceeds your plan's max size | 400 VALIDATION |
| Too many API requests from one key or IP | 429 RATE_LIMITED |
| Too many schedules aimed at a single target host (more than 60 per minute) | 429 RATE_LIMITED |
| You exceed your delivery rate | No error — schedules are dispatched in order, just throttled to your rate. Nothing is dropped. |
The monthly quota is a soft cap with 10% grace: once you pass your plan's limit you keep creating schedules (flagged over_limit) until you reach 110% of it, at which point new creates return 403 until you upgrade or the month rolls over. Schedules already queued always fire — we never drop a pending delivery because of billing. There is no automatic usage-based charging.
Query your live usage with GET /v1/usage: it returns the period, plan, schedules created, limit, grace limit, and whether you're over.
The per-target-host limit (60 schedules/minute to any one hostname) is an anti-abuse guard against using us to amplify traffic at a third party; it applies on every plan, independent of your delivery rate. Spread bursts across time or batch them with POST /v1/schedules/bulk.
See Error Codes for how to detect each of these with the SDK.
A note on precision
Every plan runs on the same engine: second-level precision with Early Firing correction. Precision is best-effort and is not a function of your plan. Every schedule records its actual fire time and the offset from when it was scheduled — see fired_at / offset_ms — so the precision you get is measured, not promised.