Bytloop Mail

Every team that sends transactional email eventually needs to read replies to it too. A password-reset email is fine to fire and forget, but “Re: onboarding question” from an actual customer needs a real inbox, not a raw JSON payload sitting in a logs table. The usual fix is running a transactional API like Resend or Postmark next to a shared inbox tool like Front — two bills, two logins, and two mental models of what is, underneath, the same email.

We hit that seam ourselves before we built anything for it: sending through one vendor and reading replies in a tool that had no idea the first one existed. Bytloop Mail is what we built instead — one workspace, one set of domains, one record of a message whether it went out through the API or came back as a reply.

POST /api/v1/emails, bearer-token auth, JSON in and out, error codes you don't need documentation open to guess at — deliberately close to how Resend, Postmark, or Mailgun already work, because there's no reason to make a developer relearn email for the fourth time. DKIM signing is handled automatically once a domain is verified, and every state change — sent, delivered, opened, clicked, bounced, complained, suppressed — fires as an HMAC-SHA256-signed webhook, retried with exponential backoff and auto-disabled after 100 straight failures, so a broken endpoint on someone's side doesn't turn into a silent, permanent gap in their events.

API keys are scoped per workspace and hashed at rest, shown only as a prefix once minted, so losing the dashboard doesn't mean losing the secret. Bounces and complaints land on the suppression list automatically — nobody has to remember to wire that up by hand — and open and click tracking is a toggle per domain rather than something forced on everywhere.

This is the part a pure email API doesn't have, and a pure shared inbox doesn't send from. Bytloop Mail's inbox works the way Gmail already trained everyone to expect — mailboxes, threads, labels, folders, filters, an auto-responder — but every message in it shares the same domains, the same suppression list, and the same delivery data as whatever went out through the API. Marketing can build a broadcast to a saved audience, support can read and reply to a customer, and an engineer can check why a transactional send bounced, all in the same workspace instead of three different records of the same address.

Workspaces are multi-tenant from the schema up: switching organizations is instant, and every resource — domains, keys, logs, contacts — is scoped to a tenant rather than filtered after the fact. Scheduled sends and inbox snoozing run through Trigger.dev background workers instead of a cron job we'd have to babysit, and the event log is built to be searched, not just written to: filter by status or recipient, then click straight through from a log row to that message's full timeline.

We also wrote comparison pages against Resend, Postmark, SendGrid, Loops, and Front, and didn't write them the way a competitor page usually reads. Each one says plainly where the other tool still wins — Postmark on deliverability reputation, SendGrid on enterprise scale, Loops on marketing-specific polish — dated, and rechecked every quarter with an open invitation to email us if something's gone stale. This product is new enough that we'd rather be accurate about the gap than pretend it isn't there.

The free tier is 3,000 emails a month on one domain and one mailbox — enough for a side project or an internal tool, no card required. Paid tiers scale by volume up through enterprise plans with dedicated IPs and an SLA. Because we're a Bangladesh-based team and know plenty of teams here can't easily put a SaaS subscription on a company card, the same tiers also exist with local pricing settled by bKash, Nagad, or bank transfer instead of a card at checkout.