Campaigns vs. transactional

Both endpoints push email through the same workers, the same IPs, and the same domains. The difference is in the input model and the rate-shaping.

Transactional (POST /emails)

• One request → one email.
• No suppression check beyond the global list (suppressions are global; campaigns add an additional list-level dedupe).
• Sent immediately (queued, then dispatched within seconds).
• No daily cap per send.
• Use for: receipts, password resets, magic links, alerts, single notifications.

Campaigns (POST /campaigns + POST /campaigns/{id}/launch)

• One campaign → many emails to a contact list.
• Render templates once per recipient with {{first_name}}, {{custom_field}} substitution.
• Per-campaign daily_cap and per_minute_cap enforced by the dispatcher.
• Send window (e.g. 10am–6pm recipient local time) respected.
• Auto-pause on bounce-rate or complaint-rate threshold breach.
• Use for: newsletters, marketing sequences, product announcements.

Why this matters

Mailbox providers treat marketing and transactional traffic differently. Mixing them on the same IP without rate-shaping is a fast way to land transactional receipts in spam.

3AVA Mail handles this by:

1. Separating IP pools by purpose — transactional pool, marketing pool, optionally per-domain.
2. Pacing campaigns — the dispatcher spreads sends across the send window, never bursts.
3. Auto-circuit-breakers — campaigns pause themselves if metrics tank; transactional sends keep flowing because they’re presumed user-triggered (and thus safer).

Choosing the right tool

Question	Use
Is this triggered by a single user action?	Transactional
Is this going to a list of >50 people?	Campaign
Does the recipient expect this within 60 seconds?	Transactional
Are you A/B testing or measuring engagement at the cohort level?	Campaign

When in doubt: if you’d be embarrassed for the recipient to see you sending to thousands of others at the same moment, it’s a campaign.