Anjal vs the Gmail API — Comparison

We have a post on why Gmail doesn't work for AI agents, and it is about a different thing: pointing automation at a Gmail account you signed up for, which breaks on Google's terms, on rate limits and eventually on a ban.

This post is about the legitimate path. You want to build on the Gmail API properly, with OAuth, so your product reads and sends from mailboxes your users already own. That is a real and supported thing to do, and for some products it is the only correct answer.

It is also not a substitute for an agent having its own address, and the two get confused constantly.

The one distinction that decides it

The Gmail API is a client onto someone else's mailbox. Everything it does happens inside an account that belongs to a person, under a grant that person gave you and can withdraw.

Anjal is a mailbox the agent owns. support-bot@yourdomain.com is not anyone's personal account. Nobody consents, nobody's private mail is in scope, and revoking it touches no human's inbox.

Pick by whose mail it is. If your product's job is "read my email and help me with it", you need the Gmail API and nothing here replaces it. If your product's job is "this agent corresponds with people", an agent-owned inbox is the right primitive and the Gmail API is a large amount of work to approximate it.

What the Gmail API actually costs to adopt

Not money, mostly. Time and compliance.

Restricted-scope verification. The scopes that let you read mail are restricted. If your servers store or transmit that data, Google requires an independent third-party security assessment under CASA. Assessor fees run $500 to $4,500 depending on complexity, the assessment takes 2 to 3 weeks at tier 2 and 4 to 6 weeks at tier 3, and it must be repeated every 12 months from the effective date of your previous Letter of Validation. That is a recurring cost and a recurring calendar item, paid to the assessor, not to Google.

A consent screen in your funnel. Every user has to click through Google OAuth and grant a scary-sounding scope before your product does anything. That is a conversion step, and for a product where the agent has its own address, it is a conversion step you did not need.

Per-user quota, not per-project. The headline numbers look enormous: 80,000,000 quota units per day per project and 1,200,000 per minute. The one that binds is 6,000 quota units per minute per user. With messages.send at 100 units, messages.get at 20 and messages.list at 5, that is roughly 60 sends a minute for a single user, or about 300 message reads. Fine for a human assistant. Not the shape you want if one mailbox is the hub for an agent doing bulk work. Google's own quota page also notes that charges for usage above the limits are planned to begin later in 2026, so the "free" part is changing.

You still build the agent parts. Threading state, drafts with approval, an audit trail that is yours rather than the user's, and a safety story for inbound text entering a model's context. Gmail gives you an API onto a mailbox, not an agent harness.

What Anjal costs to adopt

One API call. No OAuth screen, no verification, no assessment, no annual recertification, because there is no user data of Google's involved: the mailbox is yours.

curl -X POST https://anjal.app/v1/inboxes \
  -H "X-API-Key: $ANJAL_KEY" -H "Content-Type: application/json" \
  -d '{"username": "support-bot", "displayName": "Support"}'

You get an address on your domain with SPF, DKIM and DMARC handled, threads with correct Message-ID, In-Reply-To and References in both directions, IMAP and SMTP so a human can open the same mailbox in Apple Mail, a calendar, webhooks and a WebSocket, drafts so a person can approve anything going to a real customer, and prompt-injection screening on inbound before the agent reads it.

Pricing is $5/month for 2 inboxes and 6,000 emails, $15 for 10 inboxes and 20,000 emails, $199 for 200 inboxes and 150,000 emails.

Where the Gmail API is the right answer

Be clear about this, because it is often.

The agent must act as a specific person, sending from their address in their voice, with their signature, and having it appear in their Sent folder.
The agent needs their history. An agent-owned inbox starts empty. If the value is "learn from ten years of my correspondence", nothing here helps you.
You are an add-on to someone's working life: a CRM logging their sent mail, a scheduler reading their calendar, an assistant drafting from their threads.
Your users are on Workspace and IT has opinions. Domain-wide delegation and admin-controlled scopes are a governance story your buyer already understands.

If you need this, also look at Nylas, which normalises Gmail, Microsoft and IMAP behind one API and absorbs a lot of the per-provider work.

Where Anjal is the right answer

The agent corresponds as itself. It has an identity, an address on your domain, and a reputation of its own.
You want many addresses. One per customer, per campaign, per agent, created and destroyed by API. Doing that on the Gmail API means one consenting Google account per address.
You do not want a Google consent screen in your signup.
You want the mail to be yours, auditable and deletable independently of any person's account.
You want the agent reachable over MCP from Claude Code, Cursor or Codex without writing a client.

They are not mutually exclusive

Plenty of products need both, and the split is usually clean: connect the user's Gmail for the things that must happen in their mailbox, and give your agents their own Anjal addresses for the things that should not. Anjal also coexists with Google Workspace on the same domain when you want it to; see MX coexistence.

Verdict

Gmail API if the mailbox belongs to a person and that is the point. Budget the assessment, the annual recertification and the consent screen, because they are the real cost, not the code.

Anjal if the agent should have an address of its own. One API call, no review, no annual fee to a third-party assessor.

Gmail API quota figures from Google's usage limits page and assessment costs from Google's restricted scope verification documentation, both as of 2026-09. Google changes these; check the source before deciding on the numbers.