One API for Drip Sequences, Campaigns, and Transactional Email

Most dev teams run two email systems. One for transactional email (password resets, receipts, login codes) and one for marketing (newsletters, drip sequences, campaigns). This isn't a design choice. It's a constraint imposed by the tools.

Postmark explicitly bans marketing and bulk email. Their terms of service are clear: transactional only. Mailchimp has no real transactional sending API. Mandrill exists as a bolt-on, but it's a separate product with separate billing, a separate API, and a separate dashboard. So you end up paying for both.

The two-tool tax

Here's what maintaining two email systems actually costs you:

Two contact databases that drift out of sync. A user signs up and lands in your transactional system immediately. They get added to your marketing platform later via a sync job, a Zapier integration, or a manual CSV import. The records diverge. One system has their updated email address. The other still has the old one.

Unsubscribes that don't propagate. A contact unsubscribes from marketing emails in Mailchimp. Your transactional system doesn't know about it. You keep sending them receipts — which is fine — but you also send them a "we miss you" drip sequence from your app code because that contact is still marked active in Postmark's world.

No unified email history. You can't see everything you've sent to a contact in one place. Transactional sends are in one dashboard. Campaign sends are in another. When a user says "I'm getting too many emails," you have to check two systems to understand what they're receiving.

Double the integration surface. Two webhooks to configure and monitor. Two API keys to rotate. Two sets of documentation to read. Two SDKs to keep updated. Two billing relationships to manage. Two support queues to file tickets in.

This isn't hypothetical. This is the default setup for most SaaS companies with more than a few thousand users.

One API, three email types

PushMail handles drip sequences, one-off campaigns, and transactional sends in a single API. Same authentication, same contacts, same templates, same billing.

Transactional sends

Password resets, receipts, login codes. Send immediately to a single recipient:

curl -X POST https://pushmail.dev/api/v1/send \
  -H "Authorization: Bearer pm_live_abc123" \
  -H "Content-Type: application/json" \
  -d '{
    "siteId": 1,
    "to": "user@example.com",
    "templateId": 12,
    "variables": {
      "reset_url": "https://app.example.com/reset?token=xyz"
    }
  }'

Drip sequences

Multi-step automated emails with delays. Create the sequence, define the steps, then enroll contacts:

curl -X POST https://pushmail.dev/api/v1/sites/1/sequences/1/enroll \
  -H "Authorization: Bearer pm_live_abc123" \
  -H "Content-Type: application/json" \
  -d '{
    "contactId": 42
  }'

The sequence handles timing. Step 1 sends immediately. Step 2 sends 3 days later. Step 3 sends a week after that. The cron worker advances enrollments automatically. You don't write scheduling logic.

Campaigns

One-off sends to a list or segment. Schedule them or send immediately:

curl -X POST https://pushmail.dev/api/v1/campaigns \
  -H "Authorization: Bearer pm_live_abc123" \
  -H "Content-Type: application/json" \
  -d '{
    "siteId": 1,
    "name": "February product update",
    "templateId": 8,
    "listId": 3,
    "scheduledAt": "2026-02-01T10:00:00Z"
  }'

All three use the same API key. All three pull from the same contact database. All three reference the same templates. All three deduct from the same credit balance.

What this eliminates

Contact sync jobs. There's one contact database. When you update an email address or add a tag, it's reflected everywhere — sequences, campaigns, and transactional sends.

Unsubscribe gaps. When a contact unsubscribes, they're suppressed across all email types. No propagation delay, no missed webhook, no sync lag.

Fragmented analytics. Every email sent to a contact — whether it was a password reset, a drip email, or a campaign — shows up in one timeline. When a user reports "too many emails," you can see exactly what they received and when.

Redundant infrastructure. One webhook endpoint for delivery events. One API key to rotate. One set of templates to maintain. One billing account.

The comparison

When you'd still use two tools

If you're locked into Postmark for transactional delivery and you need their specific delivery infrastructure, PushMail's BYOK mode lets you bring your own SendGrid account. But you'd still be consolidating your marketing and transactional sends into one API layer.

If you're doing fewer than 100 emails a month and just need nodemailer — you don't need any of this. But the moment you need sequences or campaigns alongside your transactional email, running two systems is a tax you'll pay every month in engineering time, sync bugs, and duplicate billing.

The bottom line

Fewer integrations. Fewer sync bugs. Fewer dashboards to check. One bill. That's it.