Gmail push notification on mail
Created at 2018-03-26 Updated at 2024-11-07 - 5 min. read
I was given a task to implement gmail api of emails. So there are two approaches that can be followed. One is pushed notification while other is pull.
In this blog, we will discuss more of push method. Though if you want to implement this on mobile device, apps or browser.
One should go for pull or poll based approach. In this approach, there are two options available i.e full synchronization and partial synchronization.
In full synchronization, when the app connects to Gmail it should do a full synchronization. In this operation, your application should retrieve and store as many of the most recent message or thread as are necessary for your purpose.
In partial synchronization, you can perform a partial sync using the history.list method to return all history records newer than the startHistoryId you specify in your request. History records provide message IDs and type of change for each message, such as message added, deleted, or labels modified since the time of the startHistoryId. You can obtain and store the historyId of the most recent message from a full or partial sync to provide as a startHistoryId for future partial synchronization operations.
Limitation for this type of method is that history records are typically available for at least one week and often longer. However, the time period for which records are available may be significantly less and records may sometimes be unavailable in rare cases. If the startHistoryId supplied by your client is outside the available range of history records, the API returns an HTTP 404 error response. In this case, your client must perform a full sync as described in the previous section.
As for me, push notification will full fill my requirement. In this, we need to setup cloud pub/sub. It brings the scalability, flexibility, and reliability of enterprise message-oriented middleware to the cloud. By providing many-to-many, asynchronous messaging that decouples senders and receivers, it allows for secure and highly available communication between independently written applications.
A publisher application creates and sends messages to a topic. Subscriber applications create a subscription to a topic to receive messages from it. The subscriber can receive the message in two type i.e either pull or push. In pull delivery, your subscriber application initiates requests to the Cloud Pub/Sub server to retrieve messages. While in push delivery, Cloud Pub/Sub initiates requests to your subscriber application to deliver messages.
I would be going to push type of subscription. For this one should have HTTPS certificate on the server or domain. Then you have to register it to webmaster. Now let’s start with the practical
Create Topic
Using your Cloud Pub/Sub client, create the topic that the Gmail API should send notifications to. The topic name can be any name you choose under your project (i.e. matching projects/myproject/topics/*, where myproject is the Project ID listed for your project in the Google Developers Console).
Create Subscription
Follow the Cloud Pub/Sub Subscriber Guide to set up a subscription to the topic that you created. Configure the subscription type to be either a webhook push (i.e. HTTP POST callback) or pull (i.e. initiated by your app). This is how your application will receive notifications for updates. One can manage topic and subscription better from pub sub console.
Grant publish rights on your topic
Cloud Pub/Sub requires that you grant Gmail privileges to publish notifications to your topic.
To do this, you need to grant publish privileges to serviceAccount:[email protected]. You can do this by console
Getting Gmail mailbox updates
Once the initial Cloud Pub/Sub setup is finished, configure Gmail accounts to send notifications for mailbox updates.
Watch request
To configure Gmail accounts to send notifications to your Cloud Pub/Sub topic, simply use your Gmail API client to call watch() on the Gmail user mailbox similar to any other Gmail API call. To do so, provide the topic name created above and any other options in your watch() request, such as labels to filter on.
Things to remember
- Renew your watch in every 7 days
- Once you receive a push notification to your endpoints, remember it to respond it with status 200. Else it will repeatedly send push to the endpoint.
- Always save your startHistoryId in your database and send it to the API while retrieving the mail as the starting point.