
Gmail API - elie_CH
https://developers.google.com/gmail/api/
======
alooPotato
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.

~~~
pud
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/](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.

~~~
OmarIsmail
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

~~~
christiangenco
fyi: fut.io will send you an email asking if you want to cancel the followup
if there's a reply on the thread. I think the follow up email has to be
replied to, though.

------
bpodgursky
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.

~~~
ebbv
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.

~~~
gregschlom
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.

~~~
calpaterson
Unsuited in what way? Can you go into more detail?

------
ejain
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
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
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
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
You could label it "NSA access".

------
xienze
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.

~~~
iLoch
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
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
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.

------
chimeracoder
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.

~~~
anaphor
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.

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

------
jobu
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.

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

~~~
McGlockenshire
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.

------
cliveowen
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
It would be sweet if email, in general, was just a nice RESTful API.

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

[http://web.archive.org/web/20120421075522/http://www.prescod...](http://web.archive.org/web/20120421075522/http://www.prescod.net/rest/restmail/)

~~~
yogo
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).

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

~~~
jpb0104
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
you've just successfully invented PagerDuty (albeit cheaper and DIYed) ;)

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

------
roma1n
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.

------
milankragujevic
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.

------
vijayaggarwal
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
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)

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

------
nirajr
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?

------
roxtar
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.

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

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

------
jakozaur
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.

------
bgentry
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
Wy don't they make an open standard RESTful API which would be used across
mail providers, just like IMAP?

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

~~~
alooPotato
it does support search

EDIT: see
[https://developers.google.com/gmail/api/v1/reference/users/t...](https://developers.google.com/gmail/api/v1/reference/users/threads/list)
and look at the 'q' parameter

~~~
zak_mc_kracken
I stand happily corrected.

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

------
anonfunction
The API Overview link is dead. I expect better.

------
coherentpony
GMail desktop client? Yes please :)

~~~
pitnips
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
What is it that you want that a desktop mail client like Outlook or
Thunderbird doesn't give you?

~~~
coherentpony
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
How do you add google-api-services-gmail-v1-[version].jar to your classpath??
Where is this file?

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

------
hafichuk
The article is light on the technical details. Here's the API:
[https://developers.google.com/gmail/api/](https://developers.google.com/gmail/api/)

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

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

~~~
retejo
Yes, yes you were.

------
joedevon
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

