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

Introduction

• This guide walks through connecting a Gmail account to NGX so that replies sent to a committee role address are routed to the correct person and can be replied to using the correct identity for the committee role.
• The inbox for your website can be found at admin/inbox. Below is a screenshot of the inbox view showing conversations on the left with a preview of the threads associated with that conversation on the right.
• In order to get the benefits of this new feature, there's a bit of setup to do (see here for why) and unfortunately it's a little bit involved but it's worth it! The rest of this article is all about what you need to do to get it configured.

Note: There is now a simpler alternative that needs no Gmail account at all: see Setting up direct-to-inbox for committee replies. This Gmail route remains fully supported — pick whichever suits your group.

The work splits into three parts

1. Create a dedicated Gmail account for the role mailbox (free).
2. Create an OAuth client in Google Cloud and authorise the scope NGX needs.
3. Paste the OAuth credentials into NGX, then connect the mailbox.

Most ongoing configuration happens inside NGX. The only unavoidable manual steps in Google are creating the OAuth client once, and completing Google's consent screen for each connected mailbox.

Before you start

You need:

• Member administrator access to the NGX site you are configuring.
• A Google account to own the Google Cloud project. If you plan to connect several group mailboxes over time, own the Cloud project from one central Google account and add each group's Gmail as a test user, rather than creating a separate project per group. For a single mailbox, owning the project from that group's Gmail account is fine and you can consolidate later.
• A separate Incognito / private browsing window for each Google sign-in. This guide signs you into Google twice — into the Cloud console as the account that owns the project, and into the consent screen as the dedicated mailbox account. If you are signed into several Google accounts at once, Google quietly picks the wrong one and you will not notice until something has been created under the wrong account. Open a fresh Incognito / private window and sign in as the specific account each step needs; it also keeps the two accounts cleanly apart.

Part 1 — Create the dedicated Gmail account

Create a free Gmail account that will receive the committee mail, for our example group that is examplewalkinggroup@gmail.com.

When Google asks what the account is for, choose For my personal use. That is the option that creates a free @gmail.com account. For work or my business pushes you toward Google Workspace, which is a paid product, and For my child sets up a supervised account.

Part 2 — Create the OAuth client in Google Cloud

Go to console.cloud.google.com. Every link below opens straight on the page you need with your active project pre-selected.

Create the project and enable the Gmail API

1. Create a new project named something obvious, for example ngx-ramblers-inbox. As you type the name, Google generates a Project ID just beneath it — a globally unique string, usually your name plus a number (for example ngx-ramblers-inbox-461210). This is not the same as the project name, and it is the value you will paste into the Pub/Sub setup step later and append as ?project=<your-project-id> on the links in this guide. Before you select Create, choose Edit beside the generated ID if you want to set your own (while it is still available), and note the ID down — you cannot change it after creation. (If you need it again later, the project picker in the blue bar at the top of the console lists each project's name and ID side by side, or IAM & Admin → Settings shows the Project ID, name and number together.)
2. Enable the Gmail API — the link opens on the Gmail API itself; confirm the project and select Enable. (Manual equivalent: APIs & Services → Library → Gmail API → Enable.)

Confirm the project, then enable the Gmail API. When it finishes you see “You have successfully enabled Gmail API”.

Complete the Google Auth Platform wizard

Google has reorganised what used to be called the "OAuth consent screen" into the Google Auth Platform. The first time you open the Google Auth Platform you get a short wizard: App Information → Audience → Contact Information → Finish. It no longer asks for scopes or test users inline; those are set afterwards from the left-hand menu.

The Google Auth Platform Overview before anything is configured — select “Get started” to open the wizard.

Work through the wizard:

1. App Information — App name NGX Ramblers Inbox, and a user support email.
2. Audience — choose External.
3. Contact Information — your email address, for Google's notices.
4. Finish — agree to the policy, then Create.

Wizard step 1, App Information: an app name and a user support email.

Wizard step 2, Audience: choose External.

Wizard step 3, Contact Information: an email address for Google’s notices.

Wizard step 4, Finish: agree to the policy, then Create.

Set the audience, scope and client

With the project created, use the left-hand menu of the Google Auth Platform:

1. Audience — the page shows two sections to confirm, in this order: Publishing status, which starts as Testing (you publish it to production once the mailbox is working — see Keep the connection alive near the end of this guide, otherwise the connection dies after seven days), then User type, which should read External. Below those, under Test users, select + Add users and add the dedicated Gmail address (examplewalkinggroup@gmail.com for our example group) and your own Google address. While the app is in Testing, only listed test users can complete consent, so an account that is not listed here will be refused.

Audience: with Publishing status set to Testing and User type External, add each Gmail address under Test users.

2. Data Access — select Add or remove scopes, add https://www.googleapis.com/auth/gmail.modify, then Update and Save. This single scope lets NGX list, read, mark as read, and send messages. No broader access is requested.

Data Access → Add or remove scopes: paste https://www.googleapis.com/auth/gmail.modify into “Manually add scopes”, Add to table, then Update.

Data Access showing the single gmail.modify scope listed under Gmail scopes.

3. Clients — select Create client:
   • Application type: Web application
   • Name: something like NGX Ramblers Inbox - Example Walking Group
   • Under Authorised redirect URIs, add the URI that matches the environment you are connecting from (see the table below).
   • Select Create. A dialog shows the Client ID and Client secret — copy both now. The Client secret appears only in this dialog; once you close it, Google will not show it again.

The OAuth Overview once the wizard is complete and before any client exists — “Create OAuth client” begins the next step.

Clients → Create client: Application type Web application, a name, and the Authorised redirect URI for the environment you are connecting from.

The “OAuth client created” dialog shows the Client ID and secret — copy both before closing it, as the secret is shown only once.

If you closed the dialog without copying the secret, you do not need to start over:

• On the Clients list, open the client (click its name, or the pencil icon under Actions).
• The Client ID, Status and Client secrets live in an Additional information panel to the right of the Name/redirect-URI form. If you cannot see it, maximise the browser window — on a narrow window (an Incognito window often opens small) Google moves that panel below the Save button instead of beside the form.
• Under Client secrets, select + Add secret, then copy the value it generates (again, shown once). The Client ID is always visible here; only the secret is one-time.

If you closed the dialog, open the client and use the “Additional information” panel on the right; under Client secrets select “+ Add secret” to generate a new one.

Choosing the redirect URI

The redirect URI is where Google sends the browser back after consent. It must point at the NGX deployment you are connecting from, and it must match exactly on both sides.

You can register more than one on the same client, so a single OAuth client can serve several deployments.

Part 3 — Configure NGX and connect the mailbox

Enter the OAuth credentials

As a member administrator, open Admin → Mail Settings, open the Inbox tab (with the inbox provider set to Gmail account), and scroll to the Gmail settings, then enter:

Save the system configuration. The values are held in the database and read server-side; there is nothing to deploy or inject as an environment variable. The client secret is hidden from non-administrators. If any of the three values is missing, NGX refuses to start the consent flow and points you back to this screen.

Connect the Gmail inbox

Open Admin → Mail Settings as a member administrator, open the Inbox tab, scroll to the Gmail settings, and go to the Connected Gmail accounts step. This is also where Google returns you after the consent step:

In NGX, the Connected Gmail accounts step: select “Add Gmail inbox”, complete Google consent, and the mailbox shows as connected.

1. Select Add Gmail inbox (or Connect Gmail on an existing unconnected mailbox). NGX records the mailbox and redirects you to Google consent.
2. Sign in as the dedicated Gmail account. If you use more than one Google account, do this in a fresh Incognito / private window (see Before you start) so Google does not sign you in as the wrong one.
3. Because the app is in Testing, Google shows a "Google hasn't verified this app" warning. This is expected. Select Advanced, then Go to NGX Ramblers Inbox (unsafe), and approve.

Because the app is in Testing, Google shows a “Google hasn’t verified this app” warning; as a listed test user, continue past it.

Approve the gmail.modify access request to return to NGX, where an encrypted refresh token is stored.

4. Google returns you to NGX. The mailbox flips from "New Gmail inbox" to the connected email address, and an encrypted refresh token is stored.

Assigning further committee roles to an already connected mailbox does not require another consent flow.

Before you rely on this mailbox, publish the app to production. The refresh token you have just stored expires after seven days while the app is in Testing. The Keep the connection alive section below covers this — it is the step most people miss.

Map roles and configure forwarding

Still in the Gmail Inbox section (Mail Settings → Inbox):

• Set the Committee mailbox access policy per connected inbox. All committee role mailboxes lets any committee user view and reply to roles mapped to that inbox. Assigned roles only restricts each role to the committee members assigned to it.
• Use Role mailbox assignments to point committee role addresses at the relevant Gmail inbox.
• Select Configure forwarding on a connected inbox to create or update the Cloudflare Email Routing rules. Cloudflare sends a verification email to the Gmail destination; confirm it in Gmail, then select Configure forwarding again to apply the rules.

After confirming the Cloudflare verification email in the Gmail account, routing to the mailbox is verified.

Delivery: pull or push

Each connected mailbox has a Delivery setting on the Connected Gmail accounts step:

• Pull (default) polls Gmail every 30 seconds. No extra setup - this is the lowest-friction option and all you need for a first test.
• Push uses Gmail's real-time notifications via a Google Cloud Pub/Sub topic. NGX provisions this for you in one click rather than by hand:
  1. Add the https://www.googleapis.com/auth/cloud-platform scope to your OAuth client, on the same Data Access screen where you added gmail.modify. The one-click setup signs in with this scope.
  2. On the Pub/Sub setup step, enter a Google Cloud project ID you own and a topic name (default ngx-inbox-events), then select Run Google Cloud setup. After Google's consent screen, NGX enables the Gmail and Pub/Sub APIs, creates the topic, grants gmail-api-push@system.gserviceaccount.com the Pub/Sub Publisher role, and creates a push subscription pointed at NGX's push-receiver URL - no manual Cloud console steps.
  3. Back on the mailbox, set Delivery to Push and select Apply push. Switching back to Pull stops the watch and resumes polling.

The push registration expires after seven days; a daily job renews it and catches up on anything missed, so push degrades safely even if a notification is dropped.

Keep the connection alive: publish the app to production

While the app's Publishing status is Testing, Google expires the stored refresh token after seven days, used or not. When that happens the mailbox stops importing, its status shows a revoked token, and the error is invalid_grant. This is the most common reason a working inbox goes quiet about a week after it was first connected, and it is nothing you did wrong — it is Google's policy for an app that is still in Testing.

The fix is to take the app out of Testing once you have confirmed the mailbox connects and imports mail:

1. Open Audience (sign in as the account that owns the project, in a private window if you juggle several Google accounts).
2. Under Publishing status, select Publish app and confirm the dialog.
3. The status changes to In production, and refresh tokens stop expiring. Reconnect the mailbox once more to replace the short-lived seven-day token with a durable one.

What you do not need to do:

• You do not need to complete verification. An unverified app in production still issues working, non-expiring tokens for your own mailbox. The "Google hasn't verified this app" warning still appears at consent, and you click past it exactly as before. Verification only matters if you publish a logo or open the app to the wider public.
• Do not upload an app logo on the Branding screen. A logo forces the app into mandatory verification. For a role mailbox you want it published but unverified, so leave the logo blank.

This is a different seven-day clock from the push watch described under Delivery: pull or push. Publishing the app fixes the token; the push watch renews itself automatically. A mailbox you intend to keep running needs both, which in practice means it needs the app published to production.

Troubleshooting

Error 400: redirect_uri_mismatch on the Google sign-in screen. The redirect URI NGX sent does not exactly match any Authorised redirect URI on the OAuth client. The two values must be identical down to the scheme (http vs https), host, port, path, and the absence of a trailing slash. Compare the OAuth Redirect URI saved in NGX (Mail Settings → Inbox, Gmail Inbox section) against the Authorised redirect URIs on the client in Google Cloud → Clients, fix whichever is wrong, save, and retry. The failed Google URL contains a redirect_uri= parameter showing exactly what NGX sent.

"Google Inbox OAuth client is not configured." One or more of Client ID, Client Secret or Redirect URI is blank in the Gmail Inbox section (Mail Settings → Inbox). Fill all three and save.

"Access blocked" / the account is refused at consent. The Gmail account you are signing in as is not listed as a test user while the app is in Testing. Add it under Google Auth Platform → Audience → Test users.

“Access blocked … Error 403: access_denied” means the account signing in is not listed as a Test user while the app is in Testing.

Google did not return a refresh token. This happens if the account previously authorised the app. Remove the app's access in the Google account's security settings, then retry the consent flow.

Replies stop arriving. The usual cause is the seven-day Testing-mode token expiry described under Keep the connection alive: while the app is in Testing, Google revokes the refresh token about a week after it was issued, and the mailbox status shows a revoked token with the error invalid_grant. Publish the app to production so this stops recurring, then reconnect the mailbox to mint a fresh, durable token. (A token can also be revoked if the Gmail password changes or Google tightens a policy review.) A daily health check pings each connected mailbox, and when it finds a revoked token it now sends a push notification to the inbox so you are not left guessing. Re-scanning the general mailbox no longer clears existing threads when the token is broken — it reports the error and leaves your mail in place — and reconnecting re-imports anything missed and restarts push delivery straight away.

Recovery steps:

1. If the app's publishing status is still Testing, publish it to production first (see Keep the connection alive), otherwise the replacement token will expire again after seven days.
2. In NGX, open the Gmail Inbox section (Mail Settings → Inbox) and find the affected mailbox under Connected Gmail accounts.
3. Select Reconnect and complete Google consent as the dedicated Gmail account. If you are signed into several Google accounts, do this in a fresh Incognito / private window so Google does not pick the wrong one.
4. The mailbox returns to connected, the backlog re-imports, and push delivery restarts automatically.