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. All scopes are prefixed https://www.googleapis.com/auth/.
| Scope | Google classification | Why we need it |
|---|---|---|
gmail.modify | Restricted | Gmail workflow nodes: read messages to trigger a workflow, send replies, and apply or remove labels. This scope is requested only if you connect the Gmail integration. |
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 and update events, and trigger workflows from them. Also used to list your calendars in the editor. |
documents | Sensitive | Google Docs nodes and the document-updated trigger: read and write document content. |
youtube, youtube.upload | Sensitive | YouTube nodes: manage your channel and upload videos 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 | Non-sensitive | Firestore node: read and write documents in your Firestore database. |
openid, email, profile | Non-sensitive | “Sign in with Google” only. Gives us your email address, name and profile picture so we can create your account. Requested by a separate OAuth client that has no access to any of the scopes above. |
On minimisation. Where Google offers a narrower scope that supports the feature, we take it — drive.file rather than full Drive access, and analytics.readonly rather than write access. Where a broader scope is requested, it is because the node genuinely requires it: gmail.modify, for example, is needed for a workflow that reads an incoming message and then labels or replies to it, which no narrower Gmail scope permits.
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 only your prompt and the structure of the workflow you are editing.
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.