## Summary Add OOMOL cloud OAuth as a provider authorization source. Users can save an encrypted project API key, select a cloud provider configuration, authorize named connections, and run their actions and proxy requests through SaaS. Existing connections retain their source when the provider default changes, and third-party credentials remain in SaaS. - Implement project discovery, OAuth request synchronization, remote execution, and persistent cleanup of disconnected cloud accounts. Add SQLite, PostgreSQL, and D1 migrations and storage support, with instance reset and maintenance tooling. - Add Console project and authorization settings, localized errors, disconnect notifications, and styled OAuth completion pages that close after successful authorization. Align local development callback origins and proxy routes. - Improve safe request diagnostics and retry transient project health-check failures once. Execution requests are not automatically replayed. - Group storage implementations by database backend, share guarded HTTP requests with Marketplace, update Zod to 4.6.5, and load provider icons from the public catalog. - Document setup, maintenance, and the manual acceptance checklist. ## Validation - `npm run fix-check` passed. - `npm run build:web` passed. - Latest focused regression run: 346 tests passed across 33 files covering Console, SaaS project/client/routes, OAuth completion, and guarded HTTP requests. - Earlier implementation validation included the broader runtime/storage suites and a real PostgreSQL integration run. Full deployed action/proxy, cleanup recovery, and D1 maintenance acceptance remain documented manual checks; they are not claimed as completed by the unit tests. ## Deployment notes Apply migrations `0014_saas_project` and `0015_saas_cleanup_runtime`, configure encryption and an explicit `OOMOL_CONNECT_ORIGIN`, and enable the relevant cleanup scheduling. The remote SaaS deployment must support the project OAuth and remote execution APIs described in `docs/saas-oauth.md`.
5.0 KiB
Gmail OAuth And SDK Tutorial
This tutorial uses a local OAuth client. For a SaaS-managed Gmail account, configure its project and provider config first, then use the standard connection request endpoints with no client override. Tokens and execution stay on SaaS; reconnect preserves the saved source. See SaaS OAuth and programmatic connections.
This guide starts after you already have a Gmail OAuth client. It does not cover creating or configuring the OAuth app in Google Cloud. OpenConnector only needs the resulting client id, client secret, and a redirect URI that the OAuth app allows.
Prerequisites
- The local OpenConnector runtime can run with Node.js 22 or newer.
- You have a Gmail OAuth
clientIdandclientSecret. - The Gmail OAuth app allows this runtime's redirect URI. The URI is the current runtime origin plus
/oauth/callback.
If the runtime is reachable through a tunnel or another public origin, set OOMOL_CONNECT_ORIGIN
before starting it. The redirect URI is derived from that origin by appending /oauth/callback.
OOMOL_CONNECT_ORIGIN="https://your-runtime.example" npm run dev
For plain local development, start the runtime normally:
npm install
npm run dev
The examples below use http://localhost:3000. If you configured
OOMOL_CONNECT_ADMIN_TOKEN or a runtime token, add the matching Authorization: Bearer ... header
to admin and /v1 requests.
OAuth redirect URI is shared by all services in the same runtime. Configure the Gmail OAuth app to
allow the current runtime origin plus /oauth/callback. With the default local origin, the redirect
URI is:
http://localhost:3000/oauth/callback
1. Store The Gmail OAuth Client
Open the local console at http://localhost:3000, open the Gmail provider page, and choose
Configure OAuth Client. Paste the Gmail OAuth clientId into Client ID, paste the
clientSecret into Client Secret, then choose Save OAuth Client.
After saving, the Gmail provider page should allow you to start the connection flow.
2. Authorize A Gmail Account
After the OAuth client is configured, the Gmail provider page shows Connect Gmail. Choose that button to start the OAuth authorization flow.
Finish consent in the browser. After Gmail redirects back to the runtime, OpenConnector stores the OAuth credential as the default Gmail connection.
After the callback completes, the Gmail provider page shows the connected OAuth state.
3. Create A Runtime Token
Before calling the runtime from your own code, create a runtime token from the local console. Open the Access page, choose Create Token, name the client, and copy the token when it is shown.
Set the copied token in the shell that runs your app:
export OOMOL_CONNECT_RUNTIME_TOKEN="oct_..."
4. Verify Gmail Through HTTP
Run a Gmail Action through the runtime API with the runtime token created above:
curl -s -X POST http://localhost:3000/v1/actions/gmail.search_threads \
-H "authorization: Bearer $OOMOL_CONNECT_RUNTIME_TOKEN" \
-H 'content-type: application/json' \
-d '{"input":{"query":"newer_than:7d","maxResults":5}}'
5. Call Gmail From The SDK
Install the SDK in your TypeScript project:
npm install @oomol-lab/connector
Use OpenConnector for a self-hosted OpenConnector runtime. baseUrl is the server origin, not a
/v1 URL. Pass the runtime token you created above.
import { OpenConnector } from "@oomol-lab/connector";
const open = new OpenConnector({
baseUrl: process.env.OPENCONNECTOR_BASE_URL ?? "http://localhost:3000",
runtimeToken: process.env.OOMOL_CONNECT_RUNTIME_TOKEN,
});
const { threads } = await open.execute("gmail.search_threads", {
query: "newer_than:7d",
maxResults: 5,
});
console.log(threads);
The namespace form calls the same Action:
const { threads } = await open.gmail.search_threads({
query: "from:[email protected]",
maxResults: 5,
});
For precise Gmail Action types, install the optional types package and import the Gmail registry once in the process:
npm install -D @oomol-lab/connector-types
import "@oomol-lab/connector-types/gmail";
Common Issues
redirect_uri_mismatch: make sure the OAuth app allows the current runtime origin plus/oauth/callback.oauth_client_config_not_found: save the Gmail OAuth client in the local console before starting authorization.connection_not_found: finish the browser authorization step before calling Gmail Actions.unauthorized: create a runtime token from the Access page and pass it asOOMOL_CONNECT_RUNTIME_TOKEN.insufficient_permissions: reconnect Gmail after the OAuth app has the scopes needed by the Action you are calling.



