How to Automate Google Calendar for 50+ Clients With One n8n Workflow

If you run a scheduling agency, manage appointment booking for multiple businesses, or offer calendar automation as part of a SaaS product, you have almost certainly hit the same wall: n8n forces you to pick credentials at design time. One client means one credential. One credential means one workflow. Fifty clients means fifty copies of the same workflow, all drifting apart over time as you patch one but forget the others.

This article explains how Google Calendar OAuth works inside n8n, why it breaks down at scale, and how to architect a single workflow that handles every client's calendar through a runtime credential swap - using CredBridge as the token layer between your workflow and Google's API.

Who This Is For

This pattern is relevant if you are building or running any of the following:

Calendar agencies that manage Google Calendar for restaurant groups, medical practices, law firms, or real-estate brokers
Scheduling SaaS products built on n8n where each paying customer connects their own Google account
Appointment booking services that sync availability, create events, and send invites across dozens of client calendars
Operations consultants who automate recurring calendar tasks (weekly report events, team syncs, holiday blocking) for multiple business clients
No-code developers building client-specific automations who want to move from a "one workflow per client" model to a proper multi-tenant setup

If you are automating client onboarding workflows that include calendar provisioning, the same architecture applies. The principle is always the same: one piece of business logic, many sets of credentials.

How Google Calendar OAuth Works in n8n

Google Calendar uses OAuth 2.0 with delegated (user-level) authorization. That means every calendar you want to interact with - create events, read availability, update invites - must be authorized by the Google account that owns it. You cannot use a service account for personal Google Calendar unless you are on Google Workspace with domain-wide delegation enabled.

The Standard Setup in n8n

When you add a Google Calendar node to an n8n workflow, n8n asks you to select a credential. That credential is an OAuth 2.0 token tied to a specific Google account. Here is what happens under the hood:

You register an OAuth app in Google Cloud Console (or use n8n's hosted OAuth redirect URI).
You configure a credential in n8n with your Client ID and Client Secret.
n8n redirects through the Google OAuth consent screen to get an authorization code.
Google returns an access token (valid for 1 hour) and a refresh token (long-lived).
n8n stores both tokens and automatically refreshes the access token using the refresh token when it expires.

The Google Calendar API endpoint for listing events looks like this:

GET https://www.googleapis.com/calendar/v3/calendars/{calendarId}/events
Authorization: Bearer {access_token}

And creating an event:

POST https://www.googleapis.com/calendar/v3/calendars/{calendarId}/events
Authorization: Bearer {access_token}
Content-Type: application/json

{
  "summary": "Client Meeting",
  "start": { "dateTime": "2026-03-01T10:00:00-05:00" },
  "end":   { "dateTime": "2026-03-01T11:00:00-05:00" }
}

Common Issues With Google Calendar in n8n

Token expiry: The access token expires every 3600 seconds. n8n handles refresh automatically - but only for credentials stored in its own credential store. If you try to manage tokens outside n8n, you need to handle refresh yourself.

Scope creep: A common error is insufficientPermissions. This happens when the OAuth app was authorized with a narrow scope (calendar.readonly) but the workflow tries to write events. You need to re-authorize with https://www.googleapis.com/auth/calendar for full read-write access.

Consent screen verification: For production use, Google requires your OAuth app to go through a verification process if you request sensitive scopes. During development, you can add test users to bypass this. For a client-facing SaaS, plan for the verification timeline (it can take weeks).

Revoked tokens: If a client revokes access from their Google account settings, your refresh token becomes invalid and you get a 401 invalid_grant error. Your system needs to detect this and prompt re-authorization.

The Scaling Problem: One Workflow Per Client Is a Nightmare

Here is what the standard n8n setup looks like when you are managing calendars for, say, 20 clients:

20 separate Google credential records in n8n
20 duplicate workflows - each identical in logic but hardcoded to a different credential
When you need to change the event creation logic, you edit 20 workflows
When one client revokes their token, you track down which of the 20 workflows is broken
When you onboard client 21, you duplicate a workflow again, manually update the credential reference, and hope you do not miss anything

This is not a hypothetical - it is the reality for most n8n automation builders working with multiple clients. Community forums are full of questions like "how do I pass credentials dynamically in n8n?" The answer from core n8n is: you cannot. Credentials are resolved at design time by the node configuration, not at runtime from incoming data.

Some builders try to work around this with sub-workflows - using the Execute Workflow node to call a child workflow with a specific credential. This helps with organization but does not solve the root problem. You still have N credential records and N sub-workflow variants, one per client.

Others try to use the HTTP Request node with a hardcoded Bearer token passed in as a parameter. That works - but then you have to manage token storage, expiry, and refresh yourself, outside of n8n's built-in credential system. Most people who try this end up with stale tokens and broken automations.

The core problem: n8n's credential system is built for single-user use. It is excellent for that. It was not designed for SaaS backends or agencies that need to represent many different users within one workflow.

The Solution: One Workflow, Runtime Token Injection With CredBridge

CredBridge is purpose-built for this problem. It acts as a credential proxy: you store each client's OAuth tokens (including Google refresh tokens) in CredBridge, tagged by a tenant ID. When your n8n workflow runs, it passes the tenant ID to CredBridge via an HTTP Request node, gets back a valid access token, and uses that token in all subsequent Google Calendar API calls - all within a single workflow execution.

Here is what the architecture looks like:

Trigger (Webhook / Schedule)
  → HTTP Request node → CredBridge API  (input: tenant_id)
  ← Returns: { access_token: "ya29.xxxx", expires_in: 3599 }
  → Google Calendar API calls using that access_token

Step 1: Store Your Clients' Tokens in CredBridge

When a client completes the OAuth flow (on your website or a CredBridge-hosted page), CredBridge captures and stores their access token and refresh token. You get back a tenant_id - a stable identifier you associate with that client in your own database or CRM.

CredBridge handles token refresh automatically. When your workflow requests a token for a tenant and the access token is expired, CredBridge uses the stored refresh token to get a new one from Google, stores the updated tokens, and returns the fresh access token. Your workflow never sees a stale token.

Step 2: Set Up the n8n HTTP Request Node to Fetch the Token

In your workflow, immediately after the trigger, add an HTTP Request node configured as follows:

{
  "method": "GET",
  "url": "https://api.credbridge.io/v1/token",
  "authentication": "genericCredentialType",
  "genericAuthType": "httpHeaderAuth",
  "sendHeaders": true,
  "headerParameters": {
    "parameters": [
      {
        "name": "X-CredBridge-Key",
        "value": "{{ $env.CREDBRIDGE_API_KEY }}"
      }
    ]
  },
  "sendQuery": true,
  "queryParameters": {
    "parameters": [
      {
        "name": "tenant_id",
        "value": "={{ $json.tenant_id }}"
      },
      {
        "name": "provider",
        "value": "google"
      }
    ]
  }
}

This node receives tenant_id from your trigger payload (webhook body, schedule input, or upstream node output) and returns a valid Google access token for that specific client.

Step 3: Use the Token in Your Google Calendar API Calls

Now use the HTTP Request node (instead of the built-in Google Calendar node) to call the Google Calendar API directly, injecting the token from the previous step:

{
  "method": "POST",
  "url": "https://www.googleapis.com/calendar/v3/calendars/primary/events",
  "authentication": "none",
  "sendHeaders": true,
  "headerParameters": {
    "parameters": [
      {
        "name": "Authorization",
        "value": "=Bearer {{ $('Get Token').item.json.access_token }}"
      },
      {
        "name": "Content-Type",
        "value": "application/json"
      }
    ]
  },
  "sendBody": true,
  "bodyContentType": "json",
  "jsonBody": {
    "summary": "={{ $json.event_title }}",
    "description": "={{ $json.event_description }}",
    "start": {
      "dateTime": "={{ $json.start_time }}",
      "timeZone": "={{ $json.timezone }}"
    },
    "end": {
      "dateTime": "={{ $json.end_time }}",
      "timeZone": "={{ $json.timezone }}"
    },
    "attendees": [
      { "email": "={{ $json.attendee_email }}" }
    ]
  }
}

Note the expression {{ $('Get Token').item.json.access_token }} - this references the output of the previous HTTP Request node by its node name, pulling the access token dynamically into the Authorization header.

Step 4: Automate Client Onboarding

When a new client signs up, your onboarding flow:

Redirects them through Google OAuth (your app or CredBridge's hosted flow)
CredBridge stores their tokens and returns a tenant_id
You save that tenant_id in your CRM or database against the client record
From this point on, any workflow execution for that client passes their tenant_id - no credential configuration, no workflow duplication

This is what "automate client onboarding" looks like at the credential layer. The workflow logic stays the same for every client; only the tenant_id changes.

Full Workflow Example: Automated Weekly Calendar Summary

Here is a complete use case: every Monday morning, send each client a summary of their upcoming week's calendar events.

Workflow nodes:

Schedule Trigger - runs every Monday at 8:00 AM
Read Clients (HTTP Request or database node) - fetches list of all active clients with their tenant_id
Split In Batches - iterates over each client
Get Token (HTTP Request to CredBridge) - fetches Google access token for current client's tenant_id
Fetch Calendar Events (HTTP Request to Google Calendar API) - GET events for the next 7 days using the token
Format Summary (Function node) - builds a readable summary of events
Send Email (SMTP or Gmail node) - sends the summary to the client's email address

The entire workflow handles 50 clients in one execution. No duplicates. No per-client maintenance. When you improve the email template in step 6, it applies to every client immediately.

Handling Token Errors Gracefully

Even with CredBridge managing refresh, you should handle edge cases:

Client revoked access: CredBridge returns a token_error status. Add an IF node to check for this and route the execution to a notification path - for example, emailing the client that they need to reconnect their Google account.

Rate limiting: Google Calendar API has a quota of 1,000,000 queries per day per project. For large client lists, add a Wait node between batch iterations to avoid hitting per-second rate limits (typically 10 requests per second per user).

Timezone handling: Always pass the client's timezone in event creation. Store timezone as part of the client record and pass it through the workflow. Google Calendar API accepts IANA timezone strings like America/New_York.

Why This Beats Every Other Approach

Approach	Workflows needed	Credential maintenance	Onboarding new client
One workflow per client	N	Manual per client	Duplicate + configure
Sub-workflows per credential	N sub-workflows	Manual per client	Add new sub-workflow
Hardcoded tokens in workflow	1	You manage refresh	Update workflow variables
CredBridge token proxy	1	Automatic (CredBridge)	Add tenant via API

The CredBridge approach gives you one workflow with zero per-client workflow maintenance and automated token refresh. It scales from 1 client to 50 clients to 500 clients without any changes to your workflow.

Get Started With CredBridge

If you are running a calendar automation agency or building a scheduling SaaS on n8n, CredBridge removes the biggest technical obstacle between you and a clean multi-tenant architecture.

Solo plan - $19/month: Supports up to 10 tenants. Perfect for freelancers or small agencies just starting out.

Agency plan - $49/month: Supports up to 50 tenants. The right fit for established agencies and growing SaaS products.

Both plans include the Google OAuth token store, automatic token refresh, a tenant management dashboard, and the API endpoint your n8n workflows call at runtime.

Start at credbridge.io - connect your first Google Calendar client in under 10 minutes, without duplicating a single workflow.