Sandbox vs Production
Every new partner account starts in sandbox mode. Sandbox is a deliberately constrained version of production where:
| Limit | Sandbox | Production (default) |
|---|---|---|
| Daily send quota | 200 emails/day | 50,000 emails/day |
| Peak send rate | 1 email/second | 14 emails/second |
| Recipient restrictions | Verified-recipient addresses only (TODO; today: cap-only) | Anyone |
| Per-email price | First 200/day free | ₹0.01/email from email #1 |
| All other features | Identical to production | — |
Sandbox is NOT a free trial. It’s a probation period — we want to see you can verify a domain, configure webhooks, and send a few test emails without making the platform’s shared IP reputation worse.
Why we ship sandbox by default
In our first year of operation, ~30% of new accounts caused some form of deliverability damage in week 1. Reasons:
- Buying / scraping lists
- Testing in production with bogus recipients
- Misconfigured templates that 100% bounced
Sandbox protects everyone. Once you’ve shown a clean signal — even just a handful of successful sends + a verified domain — production access is fast.
What still works in sandbox
Everything at the API level. You can:
- Verify domain identities + email-address identities
- Create configuration sets + event destinations + templates
- Send up to 200/day to whoever
- Receive webhooks normally
- Add suppression entries + check stats + check reputation
The constraints are velocity-only — daily quota + rate limit. The functional surface is identical.
Requesting production access
curl https://apis.splashifypro.com/api/v1/partner/email/production-access \
-H "Authorization: Bearer $SPLASHIFY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"use_case": "We send transactional emails for our SaaS app — signup confirmation, password reset, payment receipts, weekly digest. ~5000 emails/day across all customers.",
"email_volume_estimate": "5000-15000 per day",
"has_unsubscribe_method": true,
"has_consent_proof": true
}'Required fields:
| Field | What we want |
|---|---|
use_case | A real description (≥30 chars). Says WHO you’re sending to + WHY they signed up |
email_volume_estimate | Realistic daily volume. Don’t overstate; quotas can be raised later |
has_unsubscribe_method | Confirm you have an unsubscribe link in marketing emails |
has_consent_proof | Confirm recipients opted in (signup, double-opt-in, purchase, etc.) |
All four must be present. Faking them violates our AUP — we audit periodically + downgrade accounts that lied.
Review timeline
Most requests are reviewed within 24 business hours. If your request:
- Has a clear use case + verified domain + zero suppression-list entries → typically approved within an hour
- Has a vague use case OR no verified domain yet → comes back with questions
- Looks like list-buying / cold outreach → denied with reason
You can resubmit any number of times after a denial — fix the flagged issue + try again.
What approval changes
sandbox: true → sandbox: false
daily_send_quota: 200 → 50,000
peak_send_rate_per_second: 1 → 14These are baseline production numbers. For higher volume reach out to support — caps can be raised on a per-partner basis.
Inspecting your status
curl https://apis.splashifypro.com/api/v1/partner/email/quotas \
-H "Authorization: Bearer $SPLASHIFY_API_KEY"Returns:
{
"daily_send_quota": 200,
"peak_send_rate_per_second": 1,
"sandbox": true,
"sent_today": 47,
"sandbox_free_used_today": 47,
"reputation_status": "HEALTHY",
...
}Common denial reasons
- No use case description. Empty + 1-line submissions are declined unread.
- No verified domain. We require at least one domain identity
in
VERIFIEDstatus before approving. Sandbox is a 5-minute exercise — verify one + resubmit. - Vague description. “Sending email to our users” isn’t enough. Tell us WHAT kind of email + HOW recipients opted in.
- Unsubscribe gap. Marketing email without an unsubscribe link is illegal under CAN-SPAM, CASL, DPDP. Fix it before requesting.
- Cold-list pattern. “We bought a list of 100K emails” is a decline.