Gmail

Seventeen operations against a connected Google account — send and reply in-thread, create and send drafts, search the inbox, read threads, and manage labels. Every string field takes {{payload.x}} templates, and the whole set can be handed to an AI Node as function-calling tools.

Overview

The Gmail node used to be a provider setting inside Email Action. It is now its own node, because the two do genuinely different things: Email Action renders a template and sends it through Resend, while Gmail talks to a real mailbox you own — with a thread history, labels, drafts and read state.

Credential and scopes

Connect a Google account under Settings › Credentials, or straight from the node's Google Account section — the picker requests the right scopes for you. Until an account is connected the node has nothing to configure and shows only that section.

Older credentials carrying just gmail.send still work for send. Everything else — drafts, labels, threads, and the AI toolkit — needs a gmail_full credential (read, modify, compose). If you see “insufficient authentication scopes”, re-authorize the credential to upgrade it in place.

Operations

Seventeen in total. Sixteen of them are offered as AI tools: sendAndWaitForResponse is not, because a tool call cannot sit and wait for a human — it only makes sense inside a pipeline, where the run pauses and resumes.

operationConfig

Every operation reads its parameters from operationConfig, and the node's form is generated from each operation's schema — pick the operation and you get exactly its fields. String values support {{payload.x}} templates.

// Create a draft reply to the sender
{
  "credentialId": "<cred-id>",
  "operation": "createDraft",
  "operationConfig": {
    "to": ["{{payload.from}}"],
    "subject": "Re: {{payload.subject}}",
    "body": "<p>Thanks for reaching out — I'll reply by end of day.</p>",
    "threadId": "{{payload.threadId}}"
  }
}

// Label every incoming invoice
{
  "credentialId": "<cred-id>",
  "operation": "addLabel",
  "operationConfig": {
    "messageId": "{{payload.id}}",
    "labelIds": ["Label_Invoices"]
  }
}

// List unread emails from a sender
{
  "credentialId": "<cred-id>",
  "operation": "listMessages",
  "operationConfig": {
    "query": "from:[email protected] is:unread",
    "maxResults": 10
  }
}

AI toolkit mode

Flip the AI toolkit card instead of picking a single operation. The Gmail node does not run an LLM in this mode — it gets exposed as 16 tools to any AI Node that picks it from the tool picker. That AI Node's model (your provider keys, your costs) reads the user message and decides which operation to call.

{
  "name": "Smart inbox toolkit",
  "credentialId": "<gmail-cred>",
  "aiEnabled": true
}

On the AI Node side, open the Tools tab → Use a workspace node as a tool and pick this node. The picker sees aiEnabled=true and offers the sixteen at once (send_email, draft_email, add_email_label, …) — check only the ones that flow needs. Each arrives with its own focused input schema, and the tool call lands here with operation already resolved.

Send and wait for a response

sendAndWaitForResponse sends the message with Approve / Disapprove links and pauses the run until someone clicks — or until the timeout you set expires. The answer arrives downstream under _waitResponse, with approved, who decided, and when.

Turn on requireDisapproveComment and a disapproval asks for a reason first; the text lands in _waitResponse.comment, ready for a downstream node to act on. Approving stays one click — asking for a justification on the happy path is friction with no upside.

Canvas integration

The node carries the Gmail logo and shows its recipient for a send, or the operation name for any of the other sixteen. Connect anything upstream that produces a payload — a trigger, a filter, an AI node — and reference its fields with the data picker.

API Reference