Google service account: setup guide for automation

A Google service account is a non-human identity that your automation uses to interact with Google APIs — Drive, Sheets, Calendar, Gmail — without requiring a user to click "Allow" every time the workflow runs. It's the difference between automation that runs unattended at 3am and automation that breaks because an OAuth token expired while you slept.

Google Cloud serves over 9 million paying customers as of 2025, and service accounts are the authentication backbone for automated workloads across nearly all of them (Google Cloud Blog). Understanding how to configure one correctly — with the right permissions and security constraints — separates reliable automation from fragile scripts that break silently.

Unlike generic AI automation posts, this guide shows real CodeWords workflows — not just theory. We'll walk through setting up a Google service account specifically for the automation workflows you'll build.

Related reading: google sheets MCP, google drive MCP server, google calendar MCP server, workflow automation tools, external secrets, CodeWords integrations, CodeWords pricing.

TL;DR

• Google service accounts authenticate server-to-server without user interaction — essential for scheduled automation, background processing, and headless workflows.
• Correct setup requires: enabling specific APIs, creating the account with minimal permissions, sharing resources (Sheets, Drive folders) with the service account email, and securing the JSON key.
• CodeWords manages Google authentication natively for Sheets, Drive, and Calendar — but understanding the underlying mechanism helps you troubleshoot and extend.

What is a Google service account and when do you need one?

Think of a service account as a robot employee with a Google identity. It has its own email address (something@project-id.iam.gserviceaccount.com), its own permissions, and its own access scope. Unlike OAuth tokens tied to a user session, a service account operates independently.

You need a service account when:

• Your automation runs on a schedule without human interaction (nightly reports, daily data syncs).
• Multiple systems share access to the same Google resources without passing user credentials around.
• Your workflow runs server-side and no browser is available for OAuth consent screens.
• You need granular permission control — giving your automation access to specific Sheets or Drive folders without granting it your entire Google account.

You don't need a service account when:

• You're building a user-facing app where each user authenticates individually (use OAuth 2.0 instead).
• You only need one-time access to a single file (just share the file with your Google account and use a token).

How do you create a Google service account step by step?

Step 1: Create or select a Google Cloud project.

Go to console.cloud.google.com. Create a new project (recommended for isolation) or select an existing one. The project acts as a container for the service account and its API access.

Step 2: Enable the APIs you need.

Navigate to APIs & Services → Library. Enable each API your automation will use:

• Google Sheets API (for spreadsheet read/write)
• Google Drive API (for file management)
• Google Calendar API (for event creation/reading)
• Gmail API (for sending emails — requires domain-wide delegation for Workspace)

Step 3: Create the service account.

Navigate to IAM & Admin → Service Accounts → Create Service Account. Name it descriptively (e.g., "codewords-automation" or "weekly-report-writer"). Skip optional permissions here — you'll scope access at the resource level instead.

Step 4: Generate a JSON key.

Click the service account → Keys tab → Add Key → Create New Key → JSON. Download the file. This is your credential — store it securely. You cannot retrieve it again. The JSON file contains the private key, client email, and project information needed for authentication.

Step 5: Share resources with the service account.

The service account's email address (visible in the console) needs explicit access to resources. For Google Sheets: open the sheet → Share → paste the service account email → give Editor access. For Drive folders: same process. Without this step, the service account sees nothing.

How do you scope permissions correctly for automation?

The principle of least privilege matters more for service accounts than human accounts because automated systems don't notice when they have access to things they shouldn't.

Resource-level sharing (preferred for most automation):

Share specific Google Sheets, Drive folders, or Calendars with the service account email. The account can only access what's explicitly shared. Simple, auditable, and easy to revoke.

IAM roles (for Google Cloud resources):

If your automation interacts with Cloud Storage, BigQuery, or other GCP services, assign IAM roles. Use predefined roles (like "Storage Object Viewer") rather than basic roles (like "Editor") to limit blast radius.

Domain-wide delegation (for Workspace admins):

Allows the service account to impersonate users in your Google Workspace domain. Required for: accessing user Gmail, reading user Calendars, or managing Drive files owned by other users. Only available to Workspace admins and should be narrowly scoped.

Google's 2025 Cloud Security report found that 65% of service account security incidents stem from over-permissioned accounts with unused access (Google Cloud Security). Audit your service accounts quarterly.

How do you use a Google service account in automation workflows?

The authentication flow for a service account is JWT-based:

1. Your code reads the JSON key file
2. Creates a signed JWT asserting the service account's identity
3. Exchanges the JWT for a short-lived access token
4. Uses the access token in API requests

In Python (the language CodeWords uses for workflows):

The google-auth library handles this. You create credentials from the service account file, scope them to the required APIs, and pass them to the Google API client. Every request is then authenticated without user interaction.

With CodeWords: You don't write this authentication code. CodeWords' native Google integrations handle credential management for Sheets, Drive, and Calendar. When you tell Cody "read data from my Google Sheet and send a summary to Slack every morning," the authentication is managed by the platform — including token refresh and error handling.

For custom Google API interactions beyond the native integrations, CodeWords supports storing your service account JSON as a secure credential accessible within your workflow's execution environment.

What are common Google service account mistakes in automation?

Mistake 1: Forgetting to share the resource. The most common issue. Your Sheet exists, the API is enabled, the key is correct — but you never shared the Sheet with the service account email. Result: 403 Forbidden.

Mistake 2: Committing the JSON key to git. The JSON key is a credential. Treat it like a password. Use environment variables, secret managers, or platform-managed credentials (like CodeWords provides).

Mistake 3: Using a single service account for everything. When one workflow needs access revoked, you break all workflows sharing that account. Create separate service accounts for separate concerns.

Mistake 4: Not monitoring for abuse. Service accounts can be compromised. Enable audit logging in Google Cloud Console and set up alerts for unusual API usage patterns.

Mistake 5: Ignoring quota limits. Google APIs have per-project quotas. A runaway automation can exhaust your project's daily quota, breaking all workflows in that project. Implement rate limiting in your automation code — or use a platform like CodeWords that handles rate-limiting for you.

How do you rotate service account keys safely?

Key rotation is a security best practice but feels risky — if you delete the old key before all systems use the new one, your automation breaks.

Safe rotation process:

1. Generate a new key (the old key remains active)
2. Update your automation to use the new key
3. Verify the new key works in production
4. Wait one full automation cycle (24 hours for daily workflows)
5. Delete the old key

For CodeWords workflows: update the stored credential in your workflow settings. The next execution uses the new key automatically. No redeployment needed.

Alternatively, use Workload Identity Federation (Google's recommended approach for 2025+), which eliminates JSON keys entirely by using identity tokens from your platform's infrastructure. This is the direction the industry is moving.

FAQs

Can a Google service account send emails via Gmail? Only with domain-wide delegation in Google Workspace. The service account impersonates a user in your domain and sends as them. Consumer Gmail accounts cannot use service accounts for sending.

How many service accounts can one project have? The default quota is 100 service accounts per project. Most automation setups need fewer than 10. If you need more, you likely need multiple projects.

Do service account credentials expire? The JSON key itself doesn't expire. The access tokens generated from it expire after 1 hour, but client libraries handle refresh automatically. Key rotation is a security practice, not a technical requirement.

Can I use a service account with CodeWords? CodeWords manages Google authentication through its native integrations for common services (Sheets, Drive, Calendar). For custom API access, you can store service account credentials securely within your workflow.

The implication

Google service accounts are infrastructure plumbing — invisible when configured correctly, painful when misconfigured. The developers who set them up properly once spend zero time on authentication issues afterward. The ones who take shortcuts spend recurring hours debugging expired tokens and permission errors.

If you want Google API automation without managing credentials, tokens, and rotation yourself, CodeWords handles it natively — so you can focus on what the workflow does, not how it authenticates.