Skip to content

Add Python template for refresh-token OAuth + per-user Google API (Gmail/Calendar/Drive) #779

@foxck016077

Description

@foxck016077

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    t-dxIssues owned by the DX team.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions