What are the rate limits?

PostNuvia is built for high-volume agent workflows. Two kinds of limits apply: how much email your plan can send, and how quickly you can call the API.

Sending limits by plan

The Free tier requires no credit card.

For full plan details, see the pricing page.

API rate limits

PostNuvia limits how quickly each organization can call the API. The limits keep the API fast and reliable for everyone: one runaway client cannot slow it down for other customers.

The limits are generous. They sit well above what agent workloads normally use, short bursts are absorbed, and almost no customer ever reaches them. Higher plans come with higher limits.

If you receive a 429

When a client goes over the limit, the API responds with 429 Too Many Requests and a Retry-After header, usually 1 second. The response body’s message and fix fields say which limit was reached and what to change.

The official SDKs retry 429 responses automatically and wait for Retry-After. If you call the API directly, do the same:

async function withRetry<T>(call: () => Promise<T>, maxRetries = 3): Promise<T> {
  for (let attempt = 0; ; attempt++) {
    try {
      return await call();
    } catch (error: any) {
      if (error.statusCode !== 429 || attempt >= maxRetries) throw error;
      const retryAfter = parseInt(error.headers?.["retry-after"] || "1");
      await new Promise((r) => setTimeout(r, retryAfter * 1000 * 2 ** attempt));
    }
  }
}

If you receive 429 responses regularly, the tips below almost always resolve it.

Tips for high-volume agents

Use webhooks or WebSockets instead of polling. Polling an inbox in a tight loop is the most common way to reach the rate limit, and it is never needed: webhooks and WebSockets deliver new messages as they arrive.

If you do poll, poll slowly. One list call every few seconds per inbox is plenty.

Spread scheduled jobs out. A job that reads many threads or messages at once should pace itself over a few minutes rather than sending every request in the first second.

Honor Retry-After. Wait the number of seconds it gives before retrying, and back off further on consecutive 429 responses.

Distribute sends across inboxes. Sending from multiple inboxes improves deliverability and avoids per-address throttling by mailbox providers. Instead of 1,000 emails from 1 inbox, send 10 emails each from 100 inboxes.

Use idempotency keys for resource creation. The clientId parameter on create operations (inboxes, pods, webhooks, drafts) prevents duplicate resources on retries. For preventing duplicate email sends, track sent message IDs in your application or use the draft workflow.

Monitor your usage. Track your sending volume against your plan limits. You can view usage in the PostNuvia Console.

Need higher limits?

Upgrading your plan raises your API rate limits along with your sending limits. For enterprise volumes, contact ceo@postnuvia.com or visit the pricing page.