Compliance
Google API Services Limited Use Disclosure
In short
Nodes2Cloud’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
In practice: your Google data flows into the workflow code running in your own Cloudflare account, not into our database. We never sell it, never use it for advertising, and never use it to train AI models.
1. Our Limited Use commitment
Nodes2Cloud’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
Concretely, that means we affirm all of the following:
- We use Google user data only to provide or improve the user-facing features that are prominent in the Nodes2Cloud interface — that is, the workflow nodes you chose to add.
- We do not transfer Google user data to third parties, except as necessary to provide those features, to comply with applicable law, or as part of a merger or acquisition with notice to you.
- We do not use Google user data for serving advertisements of any kind.
- We do not allow humans to read Google user data, unless we have your affirmative agreement for specific messages, it is necessary for security purposes such as investigating abuse, to comply with applicable law, or the data is aggregated and de-identified.
- We do not use Google user data to develop, improve or train generalised artificial intelligence or machine-learning models.
- We do not sell Google user data. We do not sell any personal data at all.
2. What the application does
Nodes2Cloud is a visual workflow builder. You design an automation as a graph of nodes; we compile that graph into Cloudflare Worker source code and deploy it into your own Cloudflare account.
If your workflow includes a Google node — “when a row is added to this sheet, send an email” — then the compiled Worker calls the Google API directly using the token you authorised. There is no execution engine of ours in the path.
Google access is entirely optional. Nodes2Cloud is fully usable without ever connecting a Google account.
3. Signing in with Google is separate from connecting an integration
This distinction matters, and we implement it as two genuinely separate OAuth clients rather than one over-scoped client:
| Sign in with Google | Connect a Google integration | |
|---|---|---|
| Purpose | Create and access your account | Let workflows act on your Google services |
| Scopes | openid, email, profile | Only the scopes for the service you chose |
| When requested | Only if you choose Google sign-in | Only when you click Connect on that integration |
| OAuth client | Dedicated sign-in client | Separate integrations client |
Signing in with Google grants no access to your Gmail, Drive, Sheets or any other service. Those require a separate, explicit consent flow.
4. Scopes we request, and why
We request a scope only when you connect that specific integration. Connecting Sheets does not grant Gmail access. Except for openid, the scope names below are prefixed https://www.googleapis.com/auth/.
| Scope | Google classification | Why we need it |
|---|---|---|
gmail.send | Sensitive | Gmail Send node: send email from your Gmail address without reading messages, drafts, labels or other mailbox data. |
spreadsheets | Sensitive | Google Sheets nodes and the “row added/updated” trigger: read and write rows. Also used to list a spreadsheet’s tabs and column headers so you can pick them from a dropdown while configuring a node. |
calendar.events | Sensitive | Google Calendar nodes: create, read, update and delete events, and trigger workflows from them. |
calendar.freebusy | Non-sensitive | Google Calendar Check Free/Busy node: query free and busy intervals for a calendar. The calendar.events scope alone does not cover this operation, so the narrower calendar.freebusy scope is requested alongside it. |
calendar.calendarlist.readonly | Non-sensitive | List the calendars you subscribe to so you can select the correct calendar while configuring a Calendar node. |
documents | Sensitive | Google Docs nodes and the document-updated trigger: read and write document content. |
youtube | Sensitive | YouTube nodes: manage your videos, playlists, ratings and channel data. |
youtube.upload | Sensitive | Upload a video to your YouTube channel from a workflow. |
analytics.readonly | Sensitive | Google Analytics node: read reports so a workflow can act on them. Read-only — we never write to your Analytics property. |
bigquery | Sensitive | BigQuery node: run queries and load data as part of a workflow. |
drive.file | Non-sensitive | Google Drive nodes: create files and access only the files your workflow created or you explicitly selected. This is the narrowest Drive scope available — we deliberately do not request full Drive access. |
datastore | Sensitive | Firestore node: read and write documents in your Firestore database. |
openid, userinfo.email, userinfo.profile | Non-sensitive | Google sign-in uses these to create and access your Nodes2Cloud account. Integrations also use userinfo.email only to label the connected Google credential. Sign-in uses a separate OAuth client with no service-data access. |
On minimisation. Where Google offers a narrower scope that supports the feature, we take it — drive.file rather than full Drive access, and gmail.send rather than mailbox read or modification access. The production app does not request Restricted Gmail or Drive scopes.
5. Where your Google data actually goes
This is the part most worth understanding:
- Almost all of it goes to your own Cloudflare Worker. Your compiled workflow calls Google directly. The spreadsheet rows, emails and calendar events it handles never touch Nodes2Cloud infrastructure.
- Our servers touch Google data in only two narrow cases, both while you are actively using the editor:
- Configuration dropdowns. To offer a list of your spreadsheet tabs, column headers, Drive folders or calendars, our API calls Google with your token and returns the names to the editor. Nothing from those calls is stored.
- Testing a single node. When you test a node in the editor, your browser normally makes the call. If Google refuses the cross-origin browser request, our API makes it instead and relays the response back to you. The response passes through in transit and is not stored.
6. What we store, and for how long
| Item | Stored? | Retention |
|---|---|---|
| OAuth access and refresh tokens | Yes — encrypted | Until you disconnect the integration or delete your account |
| Granted scopes and connection metadata | Yes | Same as above |
| Your Google email, name and profile picture (sign-in only) | Yes | While your account exists |
| Email content, spreadsheet rows, documents, files, calendar events | No | Never stored by us |
| Dropdown results (tab names, folder names, calendar names) | No | Rendered and discarded |
| Test-run requests and responses | No | Relayed in transit only |
Tokens are encrypted with AES-256-GCM under a key derived uniquely for your account, and the master key is never stored in our database. No API endpoint returns a stored token’s value.
7. Human access
No Nodes2Cloud employee or contractor reads your Google user data. There is no internal tool that displays it, and the stored tokens are not retrievable in plaintext through any interface.
The only exceptions permitted by Google’s policy, which we adopt as our own limits, are:
- where you specifically ask us to examine something and agree to it for that purpose;
- where it is necessary for security — investigating abuse or a live incident;
- where the law compels it; or
- where the data has been aggregated and de-identified.
8. AI and machine learning
Nodes2Cloud includes an AI assistant that helps design workflows. Google user data is never sent to it and never used to train any model, ours or anyone else’s. The assistant sees your prompt, the workflow you are editing (without its credentials), an example input only if you type one, and, when a trigger has a saved sample or a test run, only that input’s field names and value types: the editor removes every value before the request leaves your browser, so the contents of a Google message, file or event never reach it.
9. Transfer and sale
We do not sell Google user data, and we do not transfer it to third parties except where necessary to provide the feature you asked for — for example, your own Cloudflare account, where your workflow runs. In a merger or acquisition we would give notice before Google user data became subject to a different policy.
10. Revoking access
You can withdraw access at any time, by either route:
- In Nodes2Cloud: open Integrations in the editor and disconnect the Google integration. We delete the stored token immediately.
- In your Google account: go to myaccount.google.com/permissions and remove access for Nodes2Cloud. This works even if you cannot sign in to us.
Revoking access stops any deployed workflow that relied on it. The workflow keeps running but its Google steps will fail, because the token it uses is no longer valid. Deleting your Nodes2Cloud account also deletes all stored Google tokens.
11. Security
Tokens are encrypted at rest with per-account keys, transmitted only over TLS, decrypted only on the deployment path, and never exposed through any API response. You can additionally enable enhanced protection, where the encryption key is derived on your own device from a passkey or passphrase, so we hold no key capable of decrypting it. Full detail is on our Security page.
12. Contact
Questions about how we handle Google user data: privacy@nodes2cloud.com. Security concerns: security@nodes2cloud.com.
See also the Privacy Policy (section 5 covers Google user data) and our Sub-processors list.