Sending from your Google account

Growth can send through your ordinary Google mailbox — no domain to verify, no Amazon SES account. There are two ways in, and one of them works right now with no configuration at all.

Which route to take

Start with the app password if you want to send today. Move to the OAuth connection when you want a revocable grant and no password in play.

Sending limits — read this first

Google counts recipients, not messages, across To, Cc and Bcc:

• 500 recipients per day on a personal @gmail.com account
• 2,000 recipients per day on Google Workspace

Past the cap Google rejects the rest of the day's mail. A 3,000-contact campaign will not go out from Gmail — use Resend, Brevo or Amazon SES for lists that size, and keep Gmail for transactional mail, support replies and small segments.

Route 1 — app password (no configuration)

1. Turn on 2-step verification at myaccount.google.com/security. Google will not offer app passwords without it.

2. Create an app password at myaccount.google.com/apppasswords. Copy the 16-character value; Google never shows it again.

3. In Growth, go to Email marketing → Settings → Sending → New application and choose Custom SMTP.

   Field	Value
   SMTP host	smtp.gmail.com
   Port	465
   Implicit TLS	on
   Username	your full Google address
   Password	the 16-character app password (no spaces)
   From email	the same Google address

4. Save, then press Test.

Gmail rejects a From that is not your own address, so keep the From email and the SMTP username identical.

Route 2 — connect your Google account

This is the Connect Google button on the sending settings page. It needs a Google Cloud OAuth client once, then every organization connects in one click.

Step 1 — Google Cloud project

1. Open console.cloud.google.com and create a project (or reuse one).
2. APIs & Services → Library → Gmail API → Enable. Without this the connection succeeds and every send fails.

Step 2 — OAuth consent screen

Add exactly three scopes — openid, email, and https://www.googleapis.com/auth/gmail.send.

gmail.send lets an app send as you and grants no ability to read, modify or delete anything in the mailbox. Google classifies it as sensitive, not restricted: publishing needs a brand review, not the paid annual CASA security assessment that full-mailbox scopes require.

Then pick your audience:

• Google Workspace on your own domain → choose "Internal". No verification, ever. No 100-user cap. No token expiry. Stop here.

• Personal @gmail.com → choose "External", then press "Publish app".

  Publishing matters more than it looks. While the app sits in Testing, Google expires every refresh token after 7 days — your campaigns would break every week. Published but unverified is fine: users see an "unverified app" warning they can click through, and you are capped at 100 connected accounts. Submit for verification when you open this to customers.

Step 3 — OAuth client

APIs & Services → Credentials → Create credentials → OAuth client ID → Web application. The two flows live on different hosts, which is the single easiest thing to get wrong here:

The Gmail callback is a Convex httpAction, so it answers on the deployment's .convex.site URL. Sign-in is Better Auth, which this app serves through src/routes/api/auth/$.ts on its own domain and only proxies to Convex — so its redirect URI carries the app origin, never the Convex one.

Add every origin you sign in from. A Web-application client matches redirect URIs exactly, port included, so http://localhost:3000 and http://localhost:3058 are two separate entries — register the ports you actually run pnpm start-all on.

Step 4 — store the keys in Convex

npx convex env set GOOGLE_CLIENT_ID "<client-id>"
npx convex env set GOOGLE_CLIENT_SECRET "<client-secret>"