Gmail API

https://developers.google.com/gmail/api/

by elie_CH • 12 years ago

528 143 12 years ago

developers.google.com

jusben1369• 12 years ago

Was I the only one who thought for a moment this was another privacy related story (opening my email!)

retejo• 12 years ago

Yes, yes you were.

Dorian-Marie• 12 years ago

Here is the actual Google blog post: http://googleappsdeveloper.blogspot.com.ar/2014/06/introduci...

cliveowen• 12 years ago

This might be big, I was just done complaining about the user interface of the GMail web app. If this means that developers can now effectively create another interface on top of a real GMail API this has the potential to really change things. I can already envision several ways in how I could improve my inbox management and reduce the time spent sifting through emails.

yogo2• 12 years ago

It would be sweet if email, in general, was just a nice RESTful API.

eterps• 12 years ago

That's a really old idea that never took off:

http://web.archive.org/web/20120421075522/http://www.prescod...

toomuchtodo2• 12 years ago

http://context.io/

kurt_• 12 years ago

It's not REST but it's an HTTP API proposal: http://jmap.io/

nolite• 12 years ago

would be curious to hear some of the things you have in mind?

bpodgursky• 12 years ago

I like the idea of opening gmail up to developers via a public API, but I don't like that it comes at the cost of removing support for an open standard like IMAP. I'm worried that API access could be cut back or eliminated entirely in the future depending on developer uptake, leaving gmail entirely inaccessible to third-party applications.

Edit: I'm going off of this sentence:

It will replace IMAP, a common but complex way for applications to communicate with most email services, limiting the number of apps that can work with Gmail

Maybe it's misleading, but it sounds like the plan is to drop support.

rwbt• 12 years ago

I don't think IMAP support is going away. This is just a better API for devs to create apps for Gmail.

duskwuff• 12 years ago

It doesn't sound as though they're removing IMAP. It's still the recommended API for mail client applications. This API is a new, separate option for applications that don't need access to all your mail.

XorNot• 12 years ago

Gmail don't implement IMAP properly anyway - the IDLE command in Gmail doesn't provide notification of changes in the number of unread messages, just the existence of new ones.

It was quite a shock to find when I stopped hosting my email via GetMail/Dovecot that my read messages wouldn't automatically propagate across my devices until I did a manual poll. Gmail seems to use some HTTP API for this rather then following the standard.

alooPotato10• 12 years ago

I think its pragmatic, IMAP is just so painful.

EDIT: and inefficient

eli2• 12 years ago

The new API specifically recommends using IMAP for building a "full-fledged email client." I think you are misreading that statement.

nnnnni3• 12 years ago

I read it exactly as you did. Hopefully they won't change that!

dragonwriter4• 12 years ago

They recommend IMAP for full clients. The new API will replace IMAP for a wide variety of use cases, though (since IMAP was the only choice before it was available.)

malandrew• 12 years ago

TBH, I've never understood why more people didn't explore the multipart content type feature of email to extend email. It's typical to have plaintext and html in the same email, but why no JSON using a well defined and published JSON-schema.

alex_duf• 12 years ago

I've seen an application in production using e-mails as a message broker.

It worked pretty well.

LunaSea2• 12 years ago

Serious question: What is the use-case for email as a server communication protocol rather than say HTTP/s ?

Is it to bypass firewalls in some way ?

mtdewcmu• 12 years ago

I'm pretty sure that absolutely nothing is preventing this, and you could start sending emails with JSON inside right now. The hard part is probably finding something meaningful for it to do.

ebbv• 12 years ago

Whether they drop support or not, clearly their idea here is to replace it.

Replacing globally supported open standards with proprietary APIs is one of the things people hated about Microsoft in the past.

Why does Google seem to get a pass from so many developers for this type of behavior? Or worse, get applauded for it?

If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way. Unless you don't care about anyone but yourself.

dragonwriter4• 12 years ago

Whether they drop support or not, clearly their idea here is to replace it.

Its clearly their idea to replace it for some use cases for which IMAP's design is completely unsuited. Beyond that seems to be speculation.

If the argument is IMAP is out of date and crappy, then OK, let's make a new standard. Unilaterally making your own API is not the way.

Actually, unilaterally creating your own API, getting some real use and experience with it, and refining it and submitting it for standardization is exactly the way that useful new standards usually get created. Attempts at creating standards not based on existing unilateral APIs often result in things that no one ever implements, like XHTML 2.

pjmlp• 12 years ago

Because only Microsoft gets hate on HN.

gregschlom• 12 years ago

Having spent one year of my life trying to replicate Gmail's interface in a desktop app through IMAP (www.betterinbox.com), I can say with confidence that IMAP is completely unsuited for the Gmail paradigm. If we had this API back when we were working on BetterInbox in 2011, our lives would have been much easier.

steveklabnik• 12 years ago

It now says

Note: The Gmail API should not be used to replace IMAP for full-fledged email client access. Instead, see IMAP and SMTP.

Note the NOT.

ejain2• 12 years ago

Nice, but I'm very reluctant to give any third-party access to my mailbox. Most sites I use let me reset my password by email, so this is like handing over the keys to the castle.

andybak• 12 years ago

Yep. It would depend how granular it is. I'd like to only allow access by sender domain or something like that.

However - how many people trust our email to small web hosting companies? How much better is that?

For example - many of my clients use the mailbox provided by Webfaction who I'm sure are beyond reproach but do I trust them any more than I trust a well known SASS company that integrates using the GMail API?

ejain2• 12 years ago

Granularity is the key here.

I run a small self-tracking service (zenobase.com), and would love to let my users pull in some "metadata" from their email (e.g. the number of messages in the inbox, or the number of messages sent by hour). But I don't want my users to trust me with unrestricted access to their email.

dragonwriter4• 12 years ago

One of the advantages of this is that it allows finer-grained control than IMAP, so it can be used, e.g., for apps that can send mail (or create/read outgoing drafts) but cannot read incoming mail. So you can have at least some mail apps that don't require the "keys to the castle" that you are worried about.

thibaut_barrere• 12 years ago

It looks like auth scopes allow to restrict to read-only already [1], but I would really love to be able to restrict to a specific label/subfolder. Would provide a good level of security without having to forward the email etc, plus labels can be applied afterwards without modifying an email.

[1] https://developers.google.com/gmail/api/auth/scopes

icebraining• 12 years ago

This seems great for building bridges from Google Apps' Gmail to internal applications, though, where there's no third-party to worry about.

Being able to replace my current IMAP client code - full of hacks to convert internal ids to Gmail ids and format conversion issues - into a couple of HTTP calls sounds great to me.

hafichuk• 12 years ago

The article is light on the technical details. Here's the API: https://developers.google.com/gmail/api/

jonathonf• 12 years ago

Two key bits from the first two paragraphs of the article:

"make it easier for other Internet applications to use information in your email"

"It will replace IMAP"

First one seems par for the course, the second one doesn't seem to be reflected in the Google blog post [1]. Certainly for the moment, thankfully, it looks like IMAP is staying:

"The Gmail API should not be used to replace IMAP for full-fledged email client access" [2]

[1] http://googleappsdeveloper.blogspot.com/2014/06/introducing-... [2] https://developers.google.com/gmail/api/

essenobi• 12 years ago

I see that as being a great opportunity for customer referrals. So many people have a gmail account. It'd be cool, from the business' standpoint, to see if your customers are connected through something as simple as email if they allow an app to access sender information.

epaulson• 12 years ago

This is fantastic. What we need next are OAuth libraries for Postfix and other SMTP servers, so I can use Gmail to centralize and read my email but still use my home organization's SMTP server to send email, without having to give Google a copy of my password.

alooPotato10• 12 years ago

We (Streak, YCS11) have been using this API for a few days to build our email snoozing feature (https://www.streak.com/email-snooze-in-gmail).

The API is really nice to use and makes interacting with Gmail way easier relative to IMAP. I'm surprised they don't recommend using this API to build full email clients. I fully expected that to be one of the core use cases.

The reason its hard (currently) to build a mail client using the API is that call to list the threads in your inbox or any other label doesn't actually return the messages in those threads. So its hard to show the people that are on the thread as well as some of the timestamp. If they added some more summary data to the thread object, I could see this becoming feasible.

timjahn• 12 years ago

Totally off topic: On that page, in the image next to "Compose and Snooze", did you mean to have "Invalid Date" in the yellow box?

Pic: https://www.streak.com/images/snooze/snoozeCompose.png

aschwa12• 12 years ago

How fine grained are the permissions? Can your snoozing app operate with a sufficiently restrictive set of permissions that you are prevented from reading my email?

alooPotato10• 12 years ago

Unfortunately to snooze an email we need to be able to read the message and reinsert it. That requires full read/write permission.

If we instead just replied to the thread, we could probably get away with just read permissions.

VogonWorkEthic• 12 years ago

Your email is the least creepy thing Streak has access to. There's also a feature that tells the user when an email they've sent has been read.

the-dude• 12 years ago

About 6 months ago I helped out a woman with some computer issues. She is/was a bit paranoid, coming out of an abusive relationship.

I didn't think much of it, until I noticed access to her Gmail from Japan I seem to recall ( we are in Western Europe ).

Streak was installed into her account.

I have no idea what someone can do who has access to the Streak account. I just removed the permissions.

pud• 12 years ago

If anyone wants to snooze email without auth'ing your Gmail account, here's one I built in 2008 that's still going strong.

http://hitmelater.com/

It costs $30/yr for the high-end service but send me a note and I'll give you a link to signup for free.

chengc• 12 years ago

interesting

ten7• 12 years ago

And a competitor to you would be Follow Up Then which does what you do, I think. (http://fut.io/) I've used it for a very long time, but just switched to the snooze button in Streak. It's slick.

OmarIsmail• 12 years ago

One of the key differences between your solution (and fut.io, followup.cc) and our snooze is that we also do the conditional "but don't bring this back if there's a reply on this thread". Along with being able to "snooze" an email you're sending out with the conditional. This brings us much more in line with Boomerang's main functionality.

Plus our snoozing functionality is 100% free, no matter how many you schedule, or how long it's for :)

Oh, and you can see/edit/manage your snoozed emails all from right within Gmail.

And we also have the "Awaiting Reply" view that doesn't require you actually DO anything, other than send out emails. We show you a custom list of the last 20 emails you've sent that don't yet have a reply.

edit: added more about what features we have

akerl_• 12 years ago

Any chance your project is open source? I would do this to something like 2 emails a year, but I'm intrigued by how it works from the technical aspect. Is there a database, or just exim/postfix magic?

pfalke• 12 years ago

I couldn't image handling email without a service like this, so I've built one as my first out-of-Codecademy project. I'm kinda proud that it works!

Free to use: http://www.pfalke.com Open source: https://github.com/pfalke/returnx

craigasketch• 12 years ago

Sorry I'm super dumb :( what does 'snoozing' your email mean?

JohnBooty• 12 years ago

  > I'm surprised they don't recommend using this API to
  > build full email clients. I fully expected that to be
  > one of the core use cases.

I didn't see today's API announcement, but I'd be surprised if they wanted to encourage that. Similar to how Twitter doesn't want you to write full-fledged Twitter clients.

If we write full-fledged Gmail clients, won't they miss out on the ad revenue? Maybe not; maybe they're just glad to tie us to their service and data-mine our emails even if we're not using Google's web client.

Still, I'd be scared of basing a lot of work around this API, since they have a history of deprecating and discontinuing things in the past...

amirmc• 12 years ago

"... won't they miss out on the ad revenue?"

There's already a setting they lets you turn off ads. In any case, revenue from those ads is probably incomparable to the data-mining which they can then use to show you ads elsewhere.

lifeisstillgood• 12 years ago

Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)?

Apart from that I like the API idea - I have been beta testing my own personal document scanner - I email myself photos of bills and receipts and file them under the subject line (ie file-as bills.electricity) - it beats the hell out of a document scanner I never used.

Anyway I was going to link it to Evernote but I just don't use Evernote enough to justify it

GuiA2• 12 years ago

Seriously, I'm not trolling - why would you want to snooze an email (hide it from inbox and have it come back later - I had to go look it up)?

Example that happened to me yesterday: a colleague asks me for a piece of information that I know I can find in a book at home, but I'm at work. I snooze the email so that it doesn't fall at the bottom of my inbox, and so that it gets redelivered when I'm home and can access the book.

nairteashop• 12 years ago

why would you want to snooze an email?

I use my Gmail inbox as sort of a todo list. If a conversation is in my Inbox, it needs attention from me - I need to do some work related to it, reply to it, forward it, etc. Once I'm done with an email thread, I immediately archive it.

If you use this workflow (many do), snoozing an email is useful. I use it primarily for threads where I'm not able to reply and provide information immediately (so removing it from my inbox until I can reduces distraction), and for threads where I'd like to follow-up in a few days, if for example I don't get a reply.

jeanbebe• 12 years ago

How would you link it into Evernote?

I built a repository like Evernote where you can email and text your content for saving. Butternote.com

smackfu2• 12 years ago

AFAIK it's related to the "inbox zero" concept. You want nothing in your inbox except things that need to be actioned, but if you can't action something yet, you might want to snooze it.

dylanz2• 12 years ago

Aleem, this is great to see. We at FollowUp.cc (https://followup.cc) have been doing snoozing for quite a while and have a Chrome extension that does this as well. We are getting close to rewriting our entire extension from the ground up, and this API is definitely going to make our lives easier. Side note, I'm a big fan of Streak =)

It will be interesting to see how and if Context.io (http://context.io) starts to use this API. We use Context, and it's a fantastic product.

comex• 12 years ago

Is there any way to use this feature without all the other Streak stuff cluttering up the UI (among other things, the "box" icon on every message in list view, Pipelines on the left, big button on the top, six new buttons in compose view). The CRM stuff looks spiffy, and getting the snooze feature through you is good advertising in any case, but I don't currently have a use case for those features, so I can't use the extension if it's going to fill up the UI with them.

alooPotato10• 12 years ago

omg yes.

We're working on making all of our features togglable. Stay tuned.

tlogan• 12 years ago

Feedback: your snoozing feature is confusing because it overlaps with your reminders. Should I use reminder or snooze?

alooPotato10• 12 years ago

This is a good point. Typiucally, reminders are useful for reminding your team about a box (a deal or customer...) that needs to be looked at. Snoozed emails are just for you and remind you about a particular email.

There is clearly some overlap in use case and we're working on making that better but wanted to get out Snoozing as soon as possible.

thmorton• 12 years ago

Just a heads up, your Youtube videos on the home page won't play in Chrome if you loaded the page over HTTPS (you get a blank pop-up and the "This page contains insecure content." message). Slick product you have!

ohnoberyn2• 12 years ago

I use a small google script to "snooze" my emails. I change them to a custom label which the script looks for. The script just runs once a day and sends me a summary of ones with this label if I haven't already replied to them.

If it's useful to anyone: http://pastebin.com/c4JvjNef

Flenser• 12 years ago

The Google Apps Developer blog had a post back in 2011 showing how to do this: http://googleappsdeveloper.blogspot.co.uk/2011/07/gmail-snoo...

jasondavisfl• 12 years ago

Is your app similar to Boomerang? If so I will check it out more

mik3y• 12 years ago

My killer app for this needs webhooks, or some sort of event notification when mail arrives. Bonus points for making that condition a stored procedure/filter.

Until then I'll probably run out of "quota units" polling the thing..

eli2• 12 years ago

You could probably have your mail pass through a non-gmail server like http://www.mailgun.com/ first

toomuchtodo2• 12 years ago

You could use Zapier: https://zapier.com

alooPotato10• 12 years ago

The quotas are per user. So you can poll the /history endpoint per user. But yes, this isn't very efficient.

brousky• 12 years ago

http://context.io/docs/lite/users/webhooks

knotty66• 12 years ago

We currently use Gmail IMAP with IDLE to support this use case. It works great, so I hope they don't drop IMAP without a suitable replacement like webhooks.

jpb0104• 12 years ago

My solution. Gmail Filter -> Forward to Mandrill Email Address -> Mandrill Webhook -> POST to HTTP endpoint that will issue a Twilio voice call to my phone.

I then have my Twilio number added as a favorite contact in iOS Phone app thus bypassing the scheduled Do Not Disturb feature. I will continue to get calls every 3 minutes until I answer the call and press 5. That's my "shit hit the fan" alarm.

hughstephens• 12 years ago

you've just successfully invented PagerDuty (albeit cheaper and DIYed) ;)

chimeracoder• 12 years ago

I'm not sure what this API enables that can't be done over IMAP. IMAP may not be as familiar as JSON-over-REST, but it's supported by virtually all mail clients and providers, which makes it about as open as you can get.

Already the Gmail IMAP implementation is non-standard in a number of annoying-but-workable ways. I've been suspecting for a while that they're going to kill it or lock it down, the way they did for XMPP and Talk[0]. I really hope this isn't the first step towards that.

As bpodgursky pointed out, this sentence is troubling:

It will replace IMAP, a common but complex way for applications to communicate with most email services, limiting the number of apps that can work with Gmail

Emphasis mine.

[0] I admittedly had no evidence for this speculation before today, just a worry.

thrownaway2424• 12 years ago

Can you send mail over IMAP?

anaphor• 12 years ago

Just based on a glance of the documentation, you can permanently delete emails using this, I don't think you can do that with the IMAP interface for gmail, but I'm not 100% sure on that.

vijayaggarwal• 12 years ago

Google has been adding lots of widgets to email recently, like RSVP on invitations, itinerary on flight booking emails, etc. These are pretty useful features and I believe a lot more are possible with the APIs being opened.

However, I feel the access control is very coarse grained. For example, RSVP widget needs access to only event related emails and itinerary needs only travel booking emails, but the API spec does not allow for such fine grained control.

IMO, given that google is able bucket-ize emails into travel booking, event, etc., and even user-defined labels for any custom grouping, allowing access on such buckets would be nearly as useful and much more user-privacy friendly. For example, an accounting app could still access invoices from my inbox to update my accounts automatically. Google could even push for microformats kind of annotation to make emails semantically richer.

dmitrig01• 12 years ago

This sort of thing is already possible – anyone can add GMail actions and cards to their messages: https://developers.google.com/gmail/actions/overview

jobu• 12 years ago

It would take something pretty amazing for me to allow anyone access to my gmail account. LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.

eridius• 12 years ago

LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.

Trustworthy-seeming companies like, say, Google?

jtmoulia2• 12 years ago

Do you not give any applications IMAP access to your email?

McGlockenshire• 12 years ago

There's a tremendous difference between an email client, whose job is merely to show me my messages, and an application that is not an email client that is designed to do something to my messages other than let me read them.

Everyone's fine with the former, but the second should always give people the creeps.

mp3jeep012• 12 years ago

If they can combine this ease of accessibility for developers with a security model on the end-user side, I think it can be a solid win.

I'd love to see granularity in what the API can access, for example, TripIt may request something like "Grant access to emails from the domain travelocity.com, usairways.com, etc.," and I can know with confidence that they will not have access to the rest of my inbox.

dragonwriter4• 12 years ago

It doesn't have that level of granularity, just four auth scopes:

1) Full access to the account

2) Do everything but permanent deletes of threads and messages

3) Read everything, but no write access

4) Create/read/update/delete drafts and send messages/drafts, but no access to anything else

Finer-grained access (especially for reads, but there are some use cases for finer-grained sending controls, too) would be better, but this is, AFAIK, a step ahead of any other email API.

EDIT: source https://developers.google.com/gmail/api/auth/scopes

mp3jeep012• 12 years ago

I immediately checked for that level of scope when they announced it, my post was merely a "this would be pretty amazing for security conscious end-users" not "this part of the API is cool" -- a wishlist item have you.

dang• 12 years ago

We changed the url from http://online.wsj.com/news/article_email/google-opens-gmail-....

jakozaur• 12 years ago

Great idea. I only wish it was an open standard... Email success b/c of it openness, but if we start proprietary APIs on top of it then we are getting locked in.

joedevon• 12 years ago

Hot off the presses! Google just released the latest future ex-api they will get bored of in a couple/few years and kill, along with any company that depends on it. #rememberthiscommentthen

jimm• 12 years ago

Can't wait for the Emacs Lisp client library! (Wish I had time to work on that.)

xienze• 12 years ago

I can't believe how many people are stoked about this. If you look at https://developers.google.com/gmail/api/auth/scopes, basically apps can do a combination of a) have full control, b) read everything, c) do everything but delete emails, or d) read/write/send drafts.

Granting that level of access with no fine-grained control to 3rd party apps seems insane to me. I predict at least a couple major security incidents in the future.

iLoch2• 12 years ago

While I somewhat agree with you, it's not as though these problems didn't already exist with IMAP. I think a better way of looking at it is this is the first step in removing the password from 3rd party access. Maybe at some point in the future they'll add more fine-grained access, but for now removing the credentials from the process seems like a good first step.

Not sure why they really need an API though. Seems to me like it would have been a better solution to stick to the IMAP protocol and allow an alternative method of authorization. For example an application would request access to your email, then they'd get an access token and use that to authenticate with IMAP. They could then try to delete an email with the IMAP protocol and if they hadn't requested that scope they're receive an error.

HTTPifying everything seems to be a trend, not sure what the real purpose is - if anything it's just making things less open.

click170• 12 years ago

I too would like to know what the benefit of HTTPifying things is, aside from leveraging existing infrastructure.

This was the reason Google provided for not supporting Git in Google Code initially. They do support git now though.

scardine• 12 years ago

Google IMAP has extensions for single sign-on using OAUTH, see https://developers.google.com/gmail/xoauth2_protocol

joellarsson• 12 years ago

Yep, was hoping for more fine-grained control for reading, not just 'read everything'

coherentpony2• 12 years ago

GMail desktop client? Yes please :)

rimantas• 12 years ago

I am using Sparrow (Mac). Funny how GMail started as an the best webapp, and now I don't even remember when I last used it in "pure" form. Doesn't really help the "webapps will rule everything" message.

pitnips• 12 years ago

I've been waiting years for something like this. In the meantime, does anyone have any suggestions of third-party desktop applications that sync with gmail?

stusmall• 12 years ago

What is it that you want that a desktop mail client like Outlook or Thunderbird doesn't give you?

azncliff• 12 years ago

How do you add google-api-services-gmail-v1-[version].jar to your classpath?? Where is this file?

roma1n• 12 years ago

It's high time that we get user-controlled sandboxes that could enforce additional security restrictions and are application-transparent. If a third party app requires access (R/W) to my Google Drive files, I should be able to limit said access to a single folder, for instance, and any other content should simply be invisible to it. These restrictions should be tuneable at any time (before and after app install) and there should be visualization tools to control their effectiveness.

roxtar• 12 years ago

This raises serious privacy concerns for me.

Technical users can and will block access to portions of the API during authenticatcaion, but what about people like my parents? They might very well login, giving full permissions to the app, seeing that it's a trusted google URL while not knowing what they have done.

This is going to open a new can of worms.

bgentry• 12 years ago

My only question: can you use these APIs to mute threads? That's the one major Gmail feature that could never be done with IMAP.

niutech• 12 years ago

Wy don't they make an open standard RESTful API which would be used across mail providers, just like IMAP?

zak_mc_kracken2• 12 years ago

Sadly, the API doesn't support search, which makes it extremely limited for all but trivial apps.

alooPotato10• 12 years ago

it does support search

EDIT: see https://developers.google.com/gmail/api/v1/reference/users/t... and look at the 'q' parameter

zak_mc_kracken2• 12 years ago

I stand happily corrected.

milankragujevic• 12 years ago

I find it funny that they aren't using a Chromebook and Nexus 5 and the Nexus 7 as the product examples but instead iPhone and Macbook and iPad.

nirajr• 12 years ago

We (http://grexit.com) let users share Gmail labels. We're very happy to see this release as it has been a pain to build and scale our service over IMAP.

It'd be interesting to see what kind of limits (no. of calls, concurrency etc.) that Google has put on the API. Has anyone trying this out hit of any of these issues yet?

donniezazen• 12 years ago

Does this help with getting the new Gmail Inbox in the IMAP clients?

anonfunction• 12 years ago

The API Overview link is dead. I expect better.

nnnnni3• 12 years ago

This looks like it'd be EXTREMELY useful for cronjobs and other things where you need to send email to yourself (or another address) automatically. It would remove the need to self-host email just so that you can send status reports...

Gmail API

Related Stories