Reference · built on requestConnectorMessaging & notifications

Gmail API

Mailbox messages, threads, labels, and drafts through the Gmail API, with new-mail notifications over Cloud Pub/Sub.

Request accessPricing ↗

About

The Gmail API is Google's REST interface to a Gmail mailbox at gmail.googleapis.com. Its resources are users.messages, users.threads, users.labels, users.drafts, users.history, users.messages.attachments, and users.settings, each addressed under /gmail/v1/users/{userId}. A mailbox pushes change notices to a Cloud Pub/Sub topic once users.watch is called, and users.history.list returns what changed since a historyId. Usage is metered in quota units per method rather than requests.

Through Fibric, an operator follows a mailbox you designate, reads threads as they change, and proposes a draft, a send, or a label change for a person to approve inside Gmail.

This is a reference listing. It documents what Fibric would read from Gmail API and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • New-mail notices on a Cloud Pub/Sub topic after users.watch, each carrying emailAddress and historyId
  • Changes since a known historyId through users.history.list: messages added or deleted, labels added or removed
  • Messages and threads through users.messages.get, users.messages.list, users.threads.get, and users.threads.list
  • Attachments through users.messages.attachments.get
  • Label sets through users.labels.list, and mailbox settings such as vacation and send-as aliases through users.settings
  • Mailbox identity through users.getProfile

Proposed actions

  • Target capability: propose a reply as a draft with users.drafts.create, then send it with users.drafts.send once approved
  • Target capability: propose a message with users.messages.send
  • Target capability: propose adding or removing labels on a message or thread with users.messages.modify or users.threads.modify
  • Target capability: propose moving a message to trash with users.messages.trash, reversible with untrash

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • First reply from a shared support mailbox

    A Pub/Sub notice arrives, history.list shows the new thread, and the operator drafts a reply with users.drafts.create. A person opens the draft in Gmail, edits if needed, and it is sent with drafts.send.

    With First Response

  • Lead reply inside the hour

    Mail matching your lead label is read as it lands. The operator proposes a reply and a label change to mark it answered, with the response time recorded.

    With Lead Response

  • Quote follow-up that reads the thread

    When a quote thread goes quiet, the operator reads the thread with users.threads.get and proposes a follow-up draft in that thread for approval.

    With Quote Follow-up

Requirements

  • A Google Cloud project with the Gmail API enabled and an OAuth client
  • Consent from each mailbox owner for the scopes used; gmail.readonly, gmail.modify, and gmail.compose are restricted scopes and need restricted-scope OAuth app verification
  • A Cloud Pub/Sub topic in that project with publish rights granted to gmail-api-push@system.gserviceaccount.com
  • A users.watch call renewed at least every 7 days for each mailbox; Google recommends once per day
Authentication
OAuth 2.0 consent from the mailbox owner, granting your Google Cloud project's OAuth client the Gmail scopes it needs, such as gmail.readonly, gmail.modify, or gmail.send.

Limits

  • Quota as of May 1, 2026: 1,200,000 units per minute per project, 6,000 per minute per user, 80,000,000 per day; messages.send costs 100 units
  • Push notifications are capped at one event per second per watched user, and only signal that something changed
  • History records are typically kept for at least one week; an older startHistoryId returns 404 and forces a full sync through messages.list
  • A message may address at most 500 recipients; storing restricted-scope data on servers requires a security assessment

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Gmail API ↗

Questions and answers

How does Fibric learn about new mail?
You call users.watch with a Pub/Sub topic name. Gmail publishes a notice with emailAddress and historyId whenever the mailbox changes, at most one per second per user. Fibric then calls users.history.list from its last historyId. The watch expires after 7 days; Google recommends renewing daily.
Which scopes does it need?
Reading needs gmail.readonly and changing labels needs gmail.modify; both are restricted scopes and require restricted-scope OAuth app verification. Sending alone uses gmail.send and label management gmail.labels, which Google classes as sensitive. If restricted-scope data is stored on servers, a security assessment is required.
How is usage limited?
By quota units. As of May 1, 2026 the limits are 1,200,000 units per minute per project, 6,000 per minute per user per project, and 80,000,000 per day per project. messages.send costs 100 units, messages.get 20, messages.list 5, history.list 2, and watch 100. Google advises exponential backoff on quota errors.
Ask about Gmail API

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Gmail API through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy