Why we only request gmail.send (and why it costs us)

Most email tools you've used asked for permission to read every message you own. Maildriply does not. We ask for gmail.send and that's it.

This post explains why, what we give up, and what we believe the trade is worth.

What gmail.send lets us do

It lets us send messages on your behalf. Gmail automatically files those messages in your Sent folder. That's the entire feature surface.

It does not let us:

• List your inbox
• Read any existing message
• See message metadata (subject, recipients, dates)
• Watch your mail flow

We could not read your mail tomorrow if we wanted to. The Google OAuth grant you sign is the contract.

Why the smallest scope is the right scope

When users complain about "creepy" tracking tools, the complaint isn't usually about the tracking itself — it's about the capability gradient. The product needed to send a tracked email. The product asked for the keys to your inbox. That's the part that feels wrong.

We don't want that gradient in our product. So we declined to build features that require read access.

What we give up

A few features become harder or impossible:

1. Reply detection inside threads. Other tools poll your inbox to notice replies. We can't. Gmail's push notifications don't help either: they require a read-level scope too. Reply handling for sequences is still an open design problem for us.
2. Conversation context. We can't show you the prior thread when you're composing a reply, because we can't read the prior thread. This is a real UX cost.
3. Auto-import contacts from your inbox. Some tools build a contact graph from past correspondence. We rely on you to paste or upload recipient lists.

These costs are real. We pay them on purpose.

What we gain

• Faster Google verification. Restricted scopes (the ones that read user data) require a manual security review, sometimes weeks long, and ongoing annual audits. gmail.send is a sensitive scope, but the verification path is shorter.
• A clean answer when prospects ask. "We can't read your inbox" is not marketing copy. It's a property of the grant.
• A simpler threat model. A leaked Maildriply database does not leak anyone's email history.

The general principle

Ask for the least power that makes the product work. If you need more power later, ask then. We applied the same rule when we let AI assistants send tracked Gmail: the assistant gets no more access than we have. If you're building on the same scope, our Node.js Gmail API tutorial and Gmail API vs SMTP show it in practice. Every additional capability you carry is something the next breach is going to leak.