Mail and storage integrations

Email SMTP/IMAP

Use SMTP/IMAP for a regular mailbox where you control server credentials. SMTP enables outbound Send Email. IMAP enables inbound Email Trigger and Email Inbox Action. Required SMTP fields are host and port; username, password and from address are normally needed by the provider. Required IMAP fields are host and port; username, password and mailbox are normally needed for reading messages.

Email blocks are visible when the selected project has an Email, Gmail or Outlook integration with the matching capability. Send Email needs send capability. Email Trigger and Email Inbox Action need read or trigger capability. SMTP/IMAP integrations are not exposed through MCP in the current catalog.

Gmail

Gmail is a separate integration backed by Google OAuth and the Gmail API. Required data: auth mode, account email, OAuth client ID, OAuth client secret and refresh token. Use Google Cloud OAuth credentials and enable the Gmail API for the project. Scopes should be as narrow as possible: send-only workflows should not request broad mailbox access. Useful references: Google Cloud authentication and Gmail API scopes.

Gmail can power Send Email, Email Trigger and Email Inbox Action when the configured capabilities allow it. If MCP access is enabled, Gmail can also be exposed to assistant tools for mailbox operations supported by the connector.

Outlook

Outlook uses Microsoft Graph and is configured separately from Gmail. The managed OAuth mode depends on backend Microsoft OAuth being enabled. Manual mode needs tenant or account context, account email, client ID, client secret, refresh token and optional mailbox. Register the app in Microsoft Entra and grant Graph mail permissions appropriate for the workflow. Useful references: Microsoft Graph auth concepts, mail API overview and Graph permissions.

Outlook can power the same email blocks as Gmail: Send Email, Email Trigger and Email Inbox Action. With MCP enabled, Outlook mailbox tools can be offered to AI features where the connector supports them.

Google Drive

Google Drive is for workflow file operations against Google storage. Required data: auth mode, account email, OAuth client ID, OAuth client secret, refresh token and scope mode. Prefer drive_file when workflows should only access files created or opened by the app; use broader Drive scope only when the workflow truly needs it. Use Google Drive API authorization when choosing scopes.

Google Drive is visible in file-oriented blocks when the workflow needs read, list or write capability. It can be used by Read File, Save File, web form image fields, Web Request body files and MCP tools such as googleDrive.* after MCP access is enabled.

OneDrive

OneDrive uses Microsoft Graph file APIs and is configured separately from Google Drive. Managed OAuth requires backend Microsoft OAuth support. Manual mode needs tenant or account context, account email, client ID, client secret and refresh token. Use Microsoft Entra app registration and Graph file permissions. For scoped storage, review OneDrive and SharePoint app folders.

OneDrive appears in the same file surfaces as Google Drive when the integration has read, list or write capability: Read File, Save File, Web Request body files and MCP tools such as oneDrive.*.

AWS S3

AWS S3 is for AWS-native object storage. Required data: region, bucket, access key ID and secret access key. The bucket name must be valid for AWS S3, and credentials should come from an IAM user or role with only the bucket actions the workflow needs. Useful references: S3 request authentication, access keys and S3 security best practices.

AWS S3 appears for file reads, file saves, Web Request body files and s3.* MCP tools when storage or tool capability is enabled for the workflow.

Custom S3

Custom S3 is for S3-compatible providers such as MinIO or object stores that require a custom endpoint. Required data: endpoint, bucket, access key ID and secret access key. Region, SSL and path-style addressing depend on the provider. Use custom S3 when AWS region-based S3 settings are not enough.

Custom S3 appears in the same file surfaces as AWS S3: Read File, Save File, Web Request body files and s3.* MCP tools, provided the integration is in scope for the project.