KoltrixWhy Koltrix Enforces Send Limits in the API
Koltrix send limits are enforced by the API, not just shown on a page. What each plan allows, what a refusal looks like, and why caps protect your reputation.
On this page(7 sections)
- The limits, plan by plan
- What "enforced by the API" means
- You hear about it before you hit it
- Why hard limits instead of soft ones
- Sending reputation is shared, and slow to repair
- Runaway loops are more common than spam
- Caps instead of a warm-up dial
- Limits work alongside suppression
- Handling limits in your own code
- Key takeaways
Plenty of email products publish sending limits on a pricing page and then don't enforce them until something breaks. Koltrix does the opposite: every plan's daily and monthly caps are enforced by the API itself, at the moment a send is attempted.
That can feel strict the first time you hit a cap. This post explains what the limits are, what happens when you reach one, and why we think hard limits are kinder to customers than soft ones.
The limits, plan by plan
There are two kinds of sending limits in Koltrix:
- Daily inbox sends: mail sent by people from the team inbox.
- API and SMTP sends: mail your product sends through the REST API or the SMTP relay, counted monthly on paid plans.
Here are the numbers from our plan configuration at the time of publishing:
| Plan | Daily inbox sends | API and SMTP sends |
|---|---|---|
| Trial (7 days) | 50 per day | 200 per day |
| Starter | 500 per day | 10,000 per month |
| Pro | 2,000 per day | 50,000 per month, then $1 per 1,000 |
| Scale | Agreed per customer | Agreed per customer |
The authoritative, current numbers are always on the pricing page and in the limits reference. If this post and those pages ever disagree, trust them.
What "enforced by the API" means
When your application calls the send endpoint, the quota check happens in the same request. If the send would go over the limit, the API refuses it instead of accepting it and quietly dropping it later.
A refusal is a structured JSON response with a quota_exceeded code, which limit was hit, how much has been used, when it resets, and where to upgrade. The general shape:
{
"code": "quota_exceeded",
"error": "daily API send limit reached",
"kind": "api_sends",
"limit": 200,
"used": 200,
"window": "day",
"resets_at": "2026-10-03T00:00:00Z",
"upgrade_url": "..."
}The field names follow that shape; the values here are illustrative. Two details matter for how you handle it in code:
- Every send-quota refusal on the API is HTTP 429. The
/api/v2endpoints never answer a quota refusal with 402. The body tells you which limit was hit (kind), thelimit, how much isused, thewindow, when itresets_at, and anupgrade_url. - Windows reset on a fixed schedule. Daily caps reset each day, and monthly caps reset on the 1st of the month (UTC). A client that reads
resets_atknows exactly when retrying makes sense; one that keeps hammering before then is easy to spot in your own logs.
For the SMTP relay, a quota refusal is always a temporary 4xx reply. Sending servers treat that as "try again later" and retry on their own schedule, rather than bouncing the message back to the sender as a permanent failure.
Quota is consumed only when a send succeeds, so a request that fails validation doesn't use up your allowance.
You hear about it before you hit it
A hard limit shouldn't be a surprise. Koltrix emails the workspace when usage crosses 80%, 90% and 100% of a limit. Each warning is sent once per period, so a workspace hovering at 81% of a daily cap gets one email that day, not one per send.
If you'd rather track usage yourself, the 429 body carries enough detail (used, limit, resets_at) to build alerts in your own monitoring.
Why hard limits instead of soft ones
Sending reputation is shared, and slow to repair
Mailbox providers judge mail partly by the reputation of the infrastructure it comes from. Koltrix sends from shared infrastructure, without dedicated IPs, so one workspace that suddenly blasts a large volume of unwanted mail can hurt delivery for everyone else.
Reputation damage is fast to cause and slow to fix. A cap that stops a runaway job after a predictable number of messages is far cheaper than weeks of mail landing in spam folders.
Runaway loops are more common than spam
Most sudden spikes aren't malicious. They're bugs: a retry loop with no backoff, a job that runs once per user instead of once per day, a test script pointed at production. A limit enforced at the API turns "we emailed every customer 40 times overnight" into "some sends were refused and we got a warning email."
As our feature page puts it, a workspace can't accidentally burn the shared reputation overnight.
Caps instead of a warm-up dial
New domains need to build reputation gradually. Some providers handle this with a warm-up setting you configure. We don't: per-plan sending caps do the same protective job, without a control that looks broken when it's working as intended.
Limits work alongside suppression
Caps limit how much you can send. Suppression limits who you send to. Both protect the same reputation:
- A hard bounce suppresses the address automatically. Repeatedly sending to addresses that don't exist is one of the clearest signals of poor list hygiene.
- A spam complaint suppresses the address automatically. Nobody has to decide to stop emailing someone who reported you.
- A reply that says only "unsubscribe" suppresses the address too, because people do reply that way to transactional mail.
Most of deliverability comes down to not repeatedly sending mail to people who don't want it. Limits and suppression enforce that whether or not anyone is watching.
Handling limits in your own code
A few practical suggestions for applications sending through the API:
- Handle 429 by reading
resets_at. Queue the message and try again after the reset time, not in a tight loop. - Alert a person when a monthly limit is hit. A monthly window won't reset until the 1st, so the real fix is usually a plan decision, and the
upgrade_urlin the body points at it. - Use idempotency keys so a retry after a timeout doesn't send twice and consume quota twice.
- Separate critical from bulk sends. If a large batch job is near the limit, don't let it starve password resets. Throttle it, or schedule it for after the reset.
- Watch the warning emails. An 80% warning on day 20 of the month is a good moment to decide whether to upgrade or slow down.
Our guide to estimating transactional email costs helps work out which plan's limits fit your expected volume.
Key takeaways
- Koltrix enforces daily inbox and API/SMTP send limits in the API itself, per plan.
- A refusal on the API is always a 429 with a
quota_exceededbody that includes the limit, usage, window,resets_atand an upgrade link. Over SMTP it's a temporary 4xx. Monthly windows reset on the 1st (UTC). - Warning emails go out at 80%, 90% and 100% of a limit, once per period.
- Hard caps and automatic suppression protect shared reputation and stop runaway bugs from becoming deliverability problems.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
