Use case
When you ship an Apify Actor that calls a per-user Google API (Gmail, Calendar, Drive) and the Actor is used by buyers you do not know, the simplest auth model is refresh-token-only OAuth: the buyer pastes refresh_token, client_id, and client_secret into the input, the Actor exchanges them for a short-lived access token at runtime, hits the API, exits. No mailbox cache, no callback URL hosted on Apify, no platform-side identity storage.
This pattern is in production today on at least one public Actor (https://apify.com/foxck/gmail-inbox-intel, MIT source at https://github.com/foxck016077/apify-gmail-inbox-intel), and the end-to-end recipe is currently in review as an Academy tutorial PR: apify/apify-docs#2549.
What is missing is a 1-click starting point. Today a developer who searches "Apify Actor Gmail OAuth" finds blog posts but no apify create -t ... template that has the refresh-token exchange wired in.
Proposed template
A new Python template, working title python-google-oauth-refresh-token, containing:
INPUT_SCHEMA.json with three string fields (client_id, client_secret, refresh_token) and an optional dry_run: bool for first-touch preview
main.py with an Actor.main handler that
- branches on
dry_run and emits a synthetic dataset matching the real output schema, so a cold buyer can click Run without doing the Google Cloud Console setup
- otherwise exchanges the refresh token at
https://oauth2.googleapis.com/token for a short-lived access token
- calls a stubbed
get_data(access_token) that the developer fills in for their target Google API
scripts/oauth_setup.py that the buyer runs once on their own machine to generate the refresh token (google_auth_oauthlib.flow.InstalledAppFlow with access_type="offline", prompt="consent", Desktop app client type so no callback URL is required)
README.md linking to the Academy tutorial (once PR #2549 lands), the OAuth consent screen scope guidance, and a note that isSecret: true on the credential fields gets platform-level encryption at rest
Why a template and not just docs
Docs cover the why. A template covers the how with one command. apify create my-gmail-actor -t python-google-oauth-refresh-token lets a developer go from zero to a working Actor that calls a Google API in under 10 minutes, with all the auth boilerplate already in place. This is the same delta as the existing python-crawlee-* templates: docs explain Crawlee, the templates make it instantly runnable.
Scope and prerequisites
- Python only for the first iteration. A JS/TS equivalent can follow once the Python flow has user feedback.
- No bundled tests beyond a lint pass. The
dry_run path is the smoke test.
- No vendored credentials. The template ships with placeholder strings the developer fills in.
- Depends on no new Apify SDK feature; everything works with the current
apify Python package and google-auth-oauthlib.
Happy to draft a PR for this if it's a direction the maintainers want to take. The tutorial PR apify/apify-docs#2549 already contains 90% of the code that would go into this template, just reformatted for tutorial flow rather than template flow.
Use case
When you ship an Apify Actor that calls a per-user Google API (Gmail, Calendar, Drive) and the Actor is used by buyers you do not know, the simplest auth model is refresh-token-only OAuth: the buyer pastes
refresh_token,client_id, andclient_secretinto the input, the Actor exchanges them for a short-lived access token at runtime, hits the API, exits. No mailbox cache, no callback URL hosted on Apify, no platform-side identity storage.This pattern is in production today on at least one public Actor (https://apify.com/foxck/gmail-inbox-intel, MIT source at https://github.com/foxck016077/apify-gmail-inbox-intel), and the end-to-end recipe is currently in review as an Academy tutorial PR: apify/apify-docs#2549.
What is missing is a 1-click starting point. Today a developer who searches "Apify Actor Gmail OAuth" finds blog posts but no
apify create -t ...template that has the refresh-token exchange wired in.Proposed template
A new Python template, working title
python-google-oauth-refresh-token, containing:INPUT_SCHEMA.jsonwith three string fields (client_id,client_secret,refresh_token) and an optionaldry_run: boolfor first-touch previewmain.pywith anActor.mainhandler thatdry_runand emits a synthetic dataset matching the real output schema, so a cold buyer can click Run without doing the Google Cloud Console setuphttps://oauth2.googleapis.com/tokenfor a short-lived access tokenget_data(access_token)that the developer fills in for their target Google APIscripts/oauth_setup.pythat the buyer runs once on their own machine to generate the refresh token (google_auth_oauthlib.flow.InstalledAppFlowwithaccess_type="offline",prompt="consent", Desktop app client type so no callback URL is required)README.mdlinking to the Academy tutorial (once PR #2549 lands), the OAuth consent screen scope guidance, and a note thatisSecret: trueon the credential fields gets platform-level encryption at restWhy a template and not just docs
Docs cover the why. A template covers the how with one command.
apify create my-gmail-actor -t python-google-oauth-refresh-tokenlets a developer go from zero to a working Actor that calls a Google API in under 10 minutes, with all the auth boilerplate already in place. This is the same delta as the existingpython-crawlee-*templates: docs explain Crawlee, the templates make it instantly runnable.Scope and prerequisites
dry_runpath is the smoke test.apifyPython package andgoogle-auth-oauthlib.Happy to draft a PR for this if it's a direction the maintainers want to take. The tutorial PR
apify/apify-docs#2549already contains 90% of the code that would go into this template, just reformatted for tutorial flow rather than template flow.