{"id":"6a3465c8124a960b123aee87","title":"Notes","path":"how-to/technical-articles/2026-05-29-gmail-inbox-setup/notes","contentMarkdown":"# 29-May-2026 — Setting up a Gmail inbox for committee replies\n_____\n\n## Why each group sets this up themselves\n\nEvery group runs through these steps on its own Google account. There is **no shared central project** that all groups plug into — each group creates its **own** Google Cloud project, its **own** OAuth client, and its **own** dedicated service Gmail account(s) for the role mailboxes. The steps below describe one group's setup; another group repeats the whole thing independently.\n\nThis is deliberate, and it saves real money. Reading the contents of a Gmail mailbox uses what Google calls a **restricted scope**. For an app that's published to the public, Google requires a third-party security audit called **CASA** before it will allow that scope — roughly **£400–£1,200, repeated every year or two**. We avoid that entirely, and the way we avoid it is precisely *because* each group is self-contained:\n\n- Each group's OAuth client stays in **\"Testing\"** mode (never \"published for general distribution\").\n\n- It only ever connects to **service Gmail accounts the group itself owns** (for example a purpose-made `yourgroup-membership@gmail.com`), never a committee member's personal Gmail.\n\nGoogle assesses CASA **per OAuth client**. Because each group's client is its own little self-contained setup — one owner authorising their own service mailboxes, never published — the audit requirement simply never triggers. If we instead ran one central client that lots of different people connected their personal Gmail accounts to, that *would* trip the requirement and we'd be back to paying for verification.\n\n### What this means in practice\n\n- **The one-time \"unverified app\" warning is normal.** The first time you authorise, Google shows a screen saying it hasn't verified the app, with an \"Advanced → continue (unsafe)\" link. That's expected for a self-use setup like this — continue past it.\n\n- **Use a dedicated Gmail account, not your personal one.** Create a fresh Gmail address for each role mailbox and connect that. Keeping personal mailboxes out of it is what keeps the setup simple and free.\n\n- **Yes, it's a lot of steps.** Repeating the full Google setup per group is the trade-off for never paying for verification. It's the right call for a handful of groups; if this ever rolled out to hundreds, the setup would need rethinking.\n\n\n[Back to main article](https://ngx-ramblers.org.uk/how-to/technical-articles/2026-05-29-gmail-inbox-setup)","contentHtml":"

29-May-2026 — Setting up a Gmail inbox for committee replies

\n
\n

Why each group sets this up themselves

\n

Every group runs through these steps on its own Google account. There is no shared central project that all groups plug into — each group creates its own Google Cloud project, its own OAuth client, and its own dedicated service Gmail account(s) for the role mailboxes. The steps below describe one group's setup; another group repeats the whole thing independently.

\n

This is deliberate, and it saves real money. Reading the contents of a Gmail mailbox uses what Google calls a restricted scope. For an app that's published to the public, Google requires a third-party security audit called CASA before it will allow that scope — roughly £400–£1,200, repeated every year or two. We avoid that entirely, and the way we avoid it is precisely because each group is self-contained:

\n\n

Google assesses CASA per OAuth client. Because each group's client is its own little self-contained setup — one owner authorising their own service mailboxes, never published — the audit requirement simply never triggers. If we instead ran one central client that lots of different people connected their personal Gmail accounts to, that would trip the requirement and we'd be back to paying for verification.

\n

What this means in practice

\n\n

Back to main article

\n"}