Sending rules

Quiet hours, a frequency cap per contact, daily caps and an SMS country allow list.

Sending rules decide when marketing goes out and how much of it. Set them under Deliverability and control > Sending rules in the console, or with the API. A team that never saved rules has every rule off.

One-time codes are never held back by quiet hours or caps.

The rules

RuleWhat it does
Quiet hoursNo marketing between two times, such as 21:00 and 07:00, in a time zone you pick.
Frequency cap per contactAt most a number of marketing emails to one contact in a number of days, such as 3 a week.
Priority lanesAlways on. Codes, transactional email and marketing run on separate queues, so a large broadcast never slows a code or a receipt.
Daily caps per channelYour own limits a day for email, SMS and codes. Approximate when sending is heavy.
Backup channelIf an SMS fails, send the same message by email.
Country allow listSend SMS only to the countries you list.

Quiet hours

Quiet hours cover marketing email (broadcasts and automations) by default. You can also tick Transactional to cover the email your app sends; the console asks you to confirm, because receipts and password resets then wait too. Codes are never covered. A quiet window is at most 12 hours.

Marketing SMS can be ticked, but does nothing yet: Notix does not send marketing SMS today. It applies once it does.

You choose what happens to a message in quiet hours:

  • Hold and send (the default): the message waits and goes out when quiet hours end, spread over 30 minutes so a backlog does not leave at once.
  • Skip them: the message is not sent. Not allowed while Transactional is ticked: transactional email is only ever held, never skipped.

An email held for more than 7 days in all is not sent: it reads Failed with the reason.

Pick a time zone, or Contact's own time zone. With the second, Notix reads each contact's timezone property, an IANA zone such as Africa/Nairobi. A contact without one, or with a value that is not a real zone, uses the zone you picked.

Frequency cap

The cap covers broadcasts and automations only. It counts the broadcast and automation emails that actually went to the contact in the last days you set. When one would go past it, that email is skipped and the reason is kept on the email. It is not sent later. Transactional email, emails sent with the API and codes are never counted or capped. The cap is best effort: emails to the same contact sent at the same moment can each see room, so a contact can now and then get one more.

Daily caps

Each cap is a number a day, or empty for no cap. Days are UTC and reset at 00:00 UTC.

  • Email: when your email cap is reached, marketing email waits. The waiting emails are spread a cap's worth a day, so a large backlog goes out over several days rather than all at the next midnight. Transactional email still goes out. The email cap is best effort: it reads a count that can be up to a few seconds old, so a busy day can go a little past it.
  • SMS and codes: an SMS, or a one-time code sent by SMS, past its cap is refused with a 429 and the reason, until 00:00 UTC. These caps are counted exactly, one at a time.

Backup channel

Your choice is saved, but nothing is sent by email yet. An SMS sent through the API carries a phone number only, so Notix has no email address to fall back to.

Country allow list

With the list on, an SMS to any other country is refused with a 403 and the reason. An SMS already queued when the list is turned on is checked again just before it is sent, and refunded if it is refused. This includes test messages from the console and one-time codes sent by SMS: the list exists to stop texts to countries you never serve, which is where SMS fraud on code endpoints comes from. Use real two-letter country codes, such as NG for Nigeria.

Who is told about a change

Every change is recorded: who made it, whether in the console, the API or an AI assistant, and the rules before and after. When a change widens quiet hours, turns on skipping, or turns on the country allow list, every team admin gets an email. Records of what rules held back are kept for 90 days.

See what was held back

The page shows how many messages the rules held back this month, and a table with each message, the rule, how many and what happened: sent later, skipped or refused. Each email also says it on its own events: a held email reads Scheduled with the rule and the time it will go, a skipped one reads Cancelled with the rule.

Change rules with the API

curl -X PATCH https://app.usenotix.dev/api/v1/sending-rules \
  -H "Authorization: Bearer $NOTIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "quietHours": { "enabled": true, "from": "21:00", "to": "07:00", "timezone": "Africa/Lagos" },
    "frequencyCap": { "enabled": true, "max": 3, "windowDays": 7 }
  }'

Send only what changes. Read the rules, this month's counts and today's counts with GET /v1/sending-rules. See the Sending rules reference.

Sending rules for AI agents

An AI connected through MCP has the tools get_sending_rules and update_sending_rules. It must ask you before it changes a rule.

Who can change sending rules

In the console, every team member can see the rules. Only a team admin can change them.

With the API, every key that reads can read them. Changing them needs a full access key that is not limited to one domain, made by someone who is a team admin today. A change reaches the sending queue within 30 seconds.

Open in ClaudeOpen in ChatGPT