Retool Google Service Account Auth for REST APIs: A Practical Guide

If you've tried to set up Retool Google Service Account authentication for a REST API — whether for Google Calendar, Google Drive, or a custom backend deployed on Google Cloud Endpoints — you've likely run into the same wall: native support simply doesn't exist yet for generic REST resources. Retool does support Service Account auth for first-party Google integrations like BigQuery, Cloud Storage, and Firestore, but the moment you need it on a custom REST resource, you're on your own. This guide explains why that gap exists, what breaks when you use OAuth instead, and the best workarounds available right now.

Why Google Service Account Auth Matters for Retool REST APIs

Google Service Accounts are designed for server-to-server authentication. Instead of relying on a human user's credentials, a service account acts as a bot identity with its own permissions. This is ideal for internal tools built in Retool because:

• End users don't need a Google account or to be signed in to Google to use the app.
• You avoid token expiration issues that break apps unpredictably after a few days.
• Access is controlled at the infrastructure level, not tied to an individual's session.
• It works exactly the way the native Google Sheets resource works in Retool — seamlessly, regardless of who is logged in.

The use cases are real and common: creating Google Calendar events on behalf of your organization, managing files in a shared Google Drive for a production management system, or calling APIs protected by Google Cloud Endpoints with service account tokens.

What Breaks When You Use OAuth Instead

The most common workaround is to configure a REST API resource in Retool using OAuth 2.0 with a Bearer token. Here's a typical setup for the Google Calendar API:

• Base URL: https://www.googleapis.com/calendar/v3
• Authorization: Bearer OAUTH2_TOKEN
• OAuth Callback: https://oauth.retool.com/oauth/user/oauthcallback
• Authorization URL: Google OAuth consent screen
• Access Token URL: https://oauth2.googleapis.com/token

This works — until it doesn't. After several days of use, the refresh token silently stops working and the entire resource starts failing. The only fix is to manually re-authenticate from the resource settings page. For an app your team uses daily, this is a serious reliability problem. The root cause is that Google's OAuth refresh token flow can invalidate tokens under certain conditions (too many concurrent tokens, app re-authorization, policy changes), and Retool's REST resource doesn't always handle the refresh cycle gracefully.

Current Workarounds for Retool Service Account Auth on REST APIs

While Retool hasn't shipped native Service Account support for generic REST resources yet, here are the most practical approaches available today.

Option 1: Use a Proxy Backend to Sign Requests

Deploy a lightweight middleware service (e.g., a Cloud Run function or Cloud Function) that accepts requests from Retool, signs them with a service account using the Google Auth Library, and forwards them to the target API. Your Retool REST API resource points to your proxy, not directly to Google.

• Your proxy authenticates using a service account JSON key stored securely as an environment variable.
• It generates a short-lived id_token or access_token and attaches it to the forwarded request.
• Retool never touches Google auth directly — it just calls your proxy.

This is the most robust solution and closely mirrors what Retool does internally for BigQuery and Firestore. It adds a small amount of infrastructure but eliminates token expiration problems entirely.

Option 2: Generate and Rotate Tokens via a Retool Workflow

If you have access to Retool Workflows, you can build a workflow that calls a token-generation endpoint (e.g., a Cloud Function that returns a short-lived access token signed by your service account) and stores the result in a Retool State variable or database table. Your queries then read that token at runtime.

• Schedule the workflow to run every 45–55 minutes (Google access tokens expire after 60 minutes).
• Store the token in a retool_db table or a temporary key-value store.
• Reference the token in your REST API resource headers dynamically using a {{ }} expression.

This is more complex to maintain but keeps everything inside Retool's ecosystem without an external proxy.

Option 3: Per-Endpoint REST Resources as a Short-Term Fix

For simple use cases with a small number of API calls, you can create individual REST API resources for each endpoint and hardcode a long-lived service account token. This is not recommended for production — service account keys should be rotated — but it can unblock you quickly while you implement a more permanent solution.

What to Ask Retool to Build

The right long-term fix is for Retool to extend its existing Service Account auth implementation (already used for BigQuery, Google Cloud Storage, and Firestore) to generic REST API resources. If this affects your team, add your voice to the community thread with your specific use case. The more concrete the use case (Google Calendar event creation, Drive file management, Cloud Endpoints backends), the easier it is for the Retool team to prioritize it.

The Bottom Line

Retool Google Service Account authentication for REST APIs is a genuine gap that affects teams building reliable internal tools on Google Cloud. OAuth works as a stopgap but breaks under real-world usage conditions. A proxy backend that signs requests server-side is currently the most stable solution. If you're building a production app — especially one where end users shouldn't need their own Google credentials — invest in the proxy approach now rather than firefighting expired tokens later.