12 ms·

Gmail API

528 points by elie_CH 12y ago

jobu 12y 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 12y ago
  > LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts. Trustworthy-seeming companies like, say, Google?
- jtmoulia 12y ago
  Do you not give any applications IMAP access to your email?
  - McGlockenshire 12y 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.
jusben1369 12y ago
Was I the only one who thought for a moment this was another privacy related story (opening my email!)
- retejo 12y ago
  Yes, yes you were.
deleted 12y ago
[deleted]
Dorian-Marie 12y ago
Here is the actual Google blog post: http://googleappsdeveloper.blogspot.com.ar/2014/06/introducing-new-gmail-api.html http://googleappsdeveloper.blogspot.com.ar/2014/06/introduci...
cliveowen 12y 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.
- yogo 12y ago
  It would be sweet if email, in general, was just a nice RESTful API.
  - eterps 12y ago
    That's a really old idea that never took off: http://web.archive.org/web/20120421075522/http://www.prescod.net/rest/restmail/ http://web.archive.org/web/20120421075522/http://www.prescod...
    - yogo 12y ago
      It seems like it would take a really big, promoted initiative with major players behind it to make a shift from IMAP, but it's good to know that other people have thought about it (your comment and its siblings).
  - toomuchtodo 12y ago
    http://context.io/ http://context.io/
  - kurt_ 12y ago
    It's not REST but it's an HTTP API proposal: http://jmap.io/ http://jmap.io/
- nolite 12y ago
  would be curious to hear some of the things you have in mind?
bpodgursky 12y 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 12y ago
  I don't think IMAP support is going away. This is just a better API for devs to create apps for Gmail.
- duskwuff 12y 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 12y 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.
- alooPotato 12y ago
  I think its pragmatic, IMAP is just so painful. EDIT: and inefficient
- eli 12y ago
  The new API specifically recommends using IMAP for building a "full-fledged email client." I think you are misreading that statement.
ejain 12y 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 12y 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?
  - ejain 12y 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.
    - alooPotato 12y ago
      A meta data only permission would be cool. Access to from, to, cc, date, labels, etc for all mails but no access to the actual content would be good.
      - mrkurt 12y ago
        You could label it "NSA access".
- dragonwriter 12y 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.
hafichuk 12y ago
The article is light on the technical details. Here's the API: https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/
jonathonf 12y 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-new-gmail-api.html http://googleappsdeveloper.blogspot.com/2014/06/introducing-... [2] https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/
essenobi 12y 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 12y 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.
alooPotato 12y 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 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.
- lifeisstillgood 12y 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
  - GuiA 12y 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.
    - alialkhatib 12y ago
      Hypothetically, wouldn't really aggressive archiving accomplish the same task? Have a 0-email inbox, and if you get something that you can't address immediately (but you can take care of later in the day), then you leave it in the inbox. In the meantime, anything you can act on in some way gets acted upon and then archived. By the end of the day you would ideally have just that email in your inbox (and even in a realistic world you might have a few tasks lingering in your inbox, but few enough that you can glance and see that "task" still there). Check your email at the end of the day and act on the things you needed to postpone for whatever reason (as well as pruning emails loitering in the inbox). This requires, as previously said, really aggressive archiving, but since there's no difference between inbox and all-mail as far as I know (unless you use it as a search operator e.g. "from:friend@university.edu label:inbox"), it wouldn't be that big a cost (except that you would have to remember to archive or go through later and archive stuff). I had been doing this somewhat organically for a while - tagging emails that didn't get filtered automatically and archiving them when there was nothing more for me to do with them - but when I disabled all of my filters (a misguided experiment I don't recommend anyone attempt) I stopped.
mik3y 12y 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..
- eli 12y ago
  You could probably have your mail pass through a non-gmail server like http://www.mailgun.com/ http://www.mailgun.com/ first
- toomuchtodo 12y ago
  You could use Zapier: https://zapier.com https://zapier.com
- alooPotato 12y ago
  The quotas are per user. So you can poll the /history endpoint per user. But yes, this isn't very efficient.
- brousky 12y ago
  http://context.io/docs/lite/users/webhooks http://context.io/docs/lite/users/webhooks
- knotty66 12y 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 12y 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.
  - 12y ago
chimeracoder 12y 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 12y ago
  Can you send mail over IMAP?
- anaphor 12y 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 12y 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 12y 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 https://developers.google.com/gmail/actions/overview
mp3jeep01 12y 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.
- dragonwriter 12y 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 https://developers.google.com/gmail/api/auth/scopes
  - mp3jeep01 12y 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 12y ago
We changed the url from http://online.wsj.com/news/article_email/google-opens-gmail-making-it-more-of-a-platform-for-developers-1403719202-lMyQjAxMTA0MDIwNTEyNDUyWj http://online.wsj.com/news/article_email/google-opens-gmail-....
jakozaur 12y 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 12y 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 12y ago
Can't wait for the Emacs Lisp client library! (Wish I had time to work on that.)
xienze 12y ago
I can't believe how many people are stoked about this. If you look at https://developers.google.com/gmail/api/auth/scopes 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.
- ossreality 12y ago
  Yeah, because IMAP is far more fine grained control.
- iLoch 12y 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 12y 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.
    - yazaddaruvala 12y ago
      I think accessibility. More developers are comfortable with REST than they are with IMAP. In fact, at least the connotations I have with IMAP/SMTP: "shit still gotta learn that before I can start". Even though it would probably not even take a couple hours to get started.
coherentpony 12y ago
GMail desktop client? Yes please :)
- rimantas 12y 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 12y 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 12y ago
    What is it that you want that a desktop mail client like Outlook or Thunderbird doesn't give you?
    - coherentpony 12y ago
      They don't preserve the correct labelling. Google rolled their own IMAP implementation to support putting a single email into multiple folders without copying the email. Thunderbird will take a copy of the email if it has more than one label.
azncliff 12y ago
How do you add google-api-services-gmail-v1-[version].jar to your classpath?? Where is this file?
roma1n 12y 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 12y 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 12y 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 12y ago
Wy don't they make an open standard RESTful API which would be used across mail providers, just like IMAP?
zak_mc_kracken 12y ago
Sadly, the API doesn't support search, which makes it extremely limited for all but trivial apps.
- alooPotato 12y ago
  it does support search EDIT: see https://developers.google.com/gmail/api/v1/reference/users/threads/list https://developers.google.com/gmail/api/v1/reference/users/t... and look at the 'q' parameter
  - zak_mc_kracken 12y ago
    I stand happily corrected.
milankragujevic 12y 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 12y ago
We (http://grexit.com 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 12y ago
Does this help with getting the new Gmail Inbox in the IMAP clients?
renarenasaini 12y ago
my co-worker's sister-in-law got paid $12019 the prior week. she gets paid on the laptop and bought a $391300 house. All she did was get fortunate and put to work the steps uncovered on this web site ,,,,,,,, ,,,,,,,, WWW.MAX43.COM
anonfunction 12y ago
The API Overview link is dead. I expect better.
nnnnni 12y 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...

528 points by elie_CH 12y ago

jobu 12y 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 12y ago
> LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts. Trustworthy-seeming companies like, say, Google?
jtmoulia 12y ago
Do you not give any applications IMAP access to your email?
- McGlockenshire 12y 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.

jusben1369 12y ago

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

retejo 12y ago
Yes, yes you were.

deleted 12y ago

[deleted]

Dorian-Marie 12y ago

Here is the actual Google blog post: http://googleappsdeveloper.blogspot.com.ar/2014/06/introducing-new-gmail-api.html http://googleappsdeveloper.blogspot.com.ar/2014/06/introduci...

cliveowen 12y 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.

yogo 12y ago
It would be sweet if email, in general, was just a nice RESTful API.
- eterps 12y ago
  That's a really old idea that never took off: http://web.archive.org/web/20120421075522/http://www.prescod.net/rest/restmail/ http://web.archive.org/web/20120421075522/http://www.prescod...
  - yogo 12y ago
    It seems like it would take a really big, promoted initiative with major players behind it to make a shift from IMAP, but it's good to know that other people have thought about it (your comment and its siblings).
- toomuchtodo 12y ago
  http://context.io/ http://context.io/
- kurt_ 12y ago
  It's not REST but it's an HTTP API proposal: http://jmap.io/ http://jmap.io/
nolite 12y ago
would be curious to hear some of the things you have in mind?

bpodgursky 12y 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 12y ago
I don't think IMAP support is going away. This is just a better API for devs to create apps for Gmail.
duskwuff 12y 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 12y 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.
alooPotato 12y ago
I think its pragmatic, IMAP is just so painful. EDIT: and inefficient
eli 12y ago
The new API specifically recommends using IMAP for building a "full-fledged email client." I think you are misreading that statement.

ejain 12y 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 12y 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?
- ejain 12y 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.
  - alooPotato 12y ago
    A meta data only permission would be cool. Access to from, to, cc, date, labels, etc for all mails but no access to the actual content would be good.
    - mrkurt 12y ago
      You could label it "NSA access".
dragonwriter 12y 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.

hafichuk 12y ago

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

jonathonf 12y 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-new-gmail-api.html http://googleappsdeveloper.blogspot.com/2014/06/introducing-... [2] https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/

essenobi 12y 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 12y 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.

alooPotato 12y 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 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.

lifeisstillgood 12y 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
- GuiA 12y 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.
  - alialkhatib 12y ago
    Hypothetically, wouldn't really aggressive archiving accomplish the same task? Have a 0-email inbox, and if you get something that you can't address immediately (but you can take care of later in the day), then you leave it in the inbox. In the meantime, anything you can act on in some way gets acted upon and then archived. By the end of the day you would ideally have just that email in your inbox (and even in a realistic world you might have a few tasks lingering in your inbox, but few enough that you can glance and see that "task" still there). Check your email at the end of the day and act on the things you needed to postpone for whatever reason (as well as pruning emails loitering in the inbox). This requires, as previously said, really aggressive archiving, but since there's no difference between inbox and all-mail as far as I know (unless you use it as a search operator e.g. "from:friend@university.edu label:inbox"), it wouldn't be that big a cost (except that you would have to remember to archive or go through later and archive stuff). I had been doing this somewhat organically for a while - tagging emails that didn't get filtered automatically and archiving them when there was nothing more for me to do with them - but when I disabled all of my filters (a misguided experiment I don't recommend anyone attempt) I stopped.

mik3y 12y 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..

eli 12y ago
You could probably have your mail pass through a non-gmail server like http://www.mailgun.com/ http://www.mailgun.com/ first
toomuchtodo 12y ago
You could use Zapier: https://zapier.com https://zapier.com
alooPotato 12y ago
The quotas are per user. So you can poll the /history endpoint per user. But yes, this isn't very efficient.
brousky 12y ago
http://context.io/docs/lite/users/webhooks http://context.io/docs/lite/users/webhooks
knotty66 12y 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 12y 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.
- 12y ago

chimeracoder 12y 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 12y ago
Can you send mail over IMAP?
anaphor 12y 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 12y 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 12y 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 https://developers.google.com/gmail/actions/overview

mp3jeep01 12y 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.

dragonwriter 12y 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 https://developers.google.com/gmail/api/auth/scopes
- mp3jeep01 12y 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 12y ago

We changed the url from http://online.wsj.com/news/article_email/google-opens-gmail-making-it-more-of-a-platform-for-developers-1403719202-lMyQjAxMTA0MDIwNTEyNDUyWj http://online.wsj.com/news/article_email/google-opens-gmail-....

jakozaur 12y 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 12y 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 12y ago

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

xienze 12y ago

I can't believe how many people are stoked about this. If you look at https://developers.google.com/gmail/api/auth/scopes 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.

ossreality 12y ago
Yeah, because IMAP is far more fine grained control.
iLoch 12y 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 12y 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.
  - yazaddaruvala 12y ago
    I think accessibility. More developers are comfortable with REST than they are with IMAP. In fact, at least the connotations I have with IMAP/SMTP: "shit still gotta learn that before I can start". Even though it would probably not even take a couple hours to get started.

coherentpony 12y ago

GMail desktop client? Yes please :)

rimantas 12y 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 12y 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 12y ago
  What is it that you want that a desktop mail client like Outlook or Thunderbird doesn't give you?
  - coherentpony 12y ago
    They don't preserve the correct labelling. Google rolled their own IMAP implementation to support putting a single email into multiple folders without copying the email. Thunderbird will take a copy of the email if it has more than one label.

azncliff 12y ago

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

roma1n 12y 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 12y 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 12y 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 12y ago

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

zak_mc_kracken 12y ago

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

alooPotato 12y ago
it does support search EDIT: see https://developers.google.com/gmail/api/v1/reference/users/threads/list https://developers.google.com/gmail/api/v1/reference/users/t... and look at the 'q' parameter
- zak_mc_kracken 12y ago
  I stand happily corrected.

milankragujevic 12y 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 12y ago

We (http://grexit.com 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 12y ago

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

renarenasaini 12y ago

my co-worker's sister-in-law got paid $12019 the prior week. she gets paid on the laptop and bought a $391300 house. All she did was get fortunate and put to work the steps uncovered on this web site ,,,,,,,, ,,,,,,,, WWW.MAX43.COM

anonfunction 12y ago

The API Overview link is dead. I expect better.

nnnnni 12y 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...