# Send at a pace your domain survives

Caps per sender, per domain, per recipient — stacked, and an email goes out when every rule that matches it agrees. What cannot go now waits in a queue you can read.

[Get started](/signup)
[Documentation](https://docs.aiinbx.com/guides/pacing)

Three senders under two live rules. Each address keeps its own cadence, and together they never cross the account cap.

The rules

## Stack as many as you like

A rule is a number, a window, and what it counts per: 100 a day per sending address, 5 a day to any one person, 1 a minute across the whole account. Write as many as you want and stack them — an email goes out when every rule that matches it agrees, and waits in the queue until they do. You call send once.

One send right now, from nora@northwind.io to marco@lindmetall.de, and the five rules that match it:

Lets it go: 100 emails every day per sending address (41 of 100).

Lets it go: 500 emails every day per sending domain (118 of 500).

Lets it go: 5 emails every day per recipient (1 of 5).

Lets it go: 20 emails every hour per recipient domain (6 of 20).

Holds it: 1 email every minute across everything this rule matches (free in 12s).

Four say go, one says not yet — so it waits, and leaves the second that rule frees. Queued, not refused: you called send once, and there is nothing to retry.

Every rule carries its own patterns — \*@acme.com for a whole domain, billing@\* for a local part wherever it turns up — so a rule only has a say over the mail you point it at, and \* for every send. A rule with no patterns catches nothing.

In the console

## Everything that is waiting, and what for

The console's pacing queue: 1,284 emails waiting, the next going out tomorrow at 09:00 when the Business hours rule lets it. A bar shows what holds them back (Business hours 812, Warm-up 340, on its way 132), and every waiting email is listed with its sender, recipient, subject, send time and the rule holding it.

Nothing is dropped

A send that a rule holds is accepted, not refused. It sits in the queue and leaves the moment every rule that matches it agrees.

Which rule, not how many

The number held is the least useful thing on the page. The bar over it names the rule doing the holding, which is the one you would change.

Override by hand

Something urgent stuck behind a warm-up goes out on one click, or one call, whether or not the rule was ready for it.

In your code

## Nothing to schedule, nothing to retry

Step 1, pacingRules.create: written once, in code or in the console.

```
await aiinbx.pacingRules.create({
  name: "Warm the new domain",
  kind: "limit",
  match: [{ field: "from", pattern: "*@new.northwind.io" }],
  limit: { scope: "from_domain", amount: 200, per_seconds: 3600 },
})
```

Step 2, emails.send: accepted either way, and honest about which.

```
const email = await aiinbx.emails.send(payload)

if (email.pacing) {
  console.log(email.pacing.held_by, email.pacing.estimated_send_at)
}
```

Step 3, the one that must not wait: password resets, login codes, security alerts.

```
await aiinbx.emails.send({
  ...reset,
  pacing: { skip: true, count: false },
})
```

Around it

## What else decides when mail leaves

Sending hours

The other kind of rule in the same list: a timezone and the hours mail may leave in it, so nothing lands at 3am on a Sunday.

Spread

Perfectly even gaps are one of the cheaper tells of automation. One dial from 0 to 100 varies them, at a little throughput.

One space per customer

A rule in a customer's space reads their mail alone and stacks under yours — they can tighten what they send, never loosen your cap.

Ceilings you start with

The domain every workspace starts with — <slug>.aiinbx.app — comes paced: 100 a day, 20 an hour, 10 a day to any one person. A domain of your own is held to none of it.

## Give your product an inbox. The hard parts are already handled.

[Get started](/signup)