Gmail API(developers.google.com)
developers.google.com
Gmail API
https://developers.google.com/gmail/api/
146 comments
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.
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.
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
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
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.
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.
There is also our product, FollowUp.cc (https://followup.cc). We've been around for a little over 7 years!
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
Free to use: http://www.pfalke.com Open source: https://github.com/pfalke/returnx
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?
Sorry I'm super dumb :( what does 'snoozing' your email mean?
Hide it for the desired time, and then show up again as unread.
interesting
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
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
> 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.
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.
gmail lets you create tasks on emails. Any reason you don't use that instead?
Sounds like you should start using flags instead ("stars" in web-gmail?) Then your todo list should be easily accessible through a filtered list of flagged messages. Most IMAP clients offer this out of the box.
I have labels for organization but once something is marked as read or out of my priority inbox (where starred emails go) is has an extremely low priority and might as well not exist. If it's in my inbox and unread it gives me anxiety not to action it. A Snooze feature is a perfect middle ground.
Gmail also offers a nifty "Starred First" view which keeps the last 10 or so starred emails at the top
http://i.imgur.com/0Vokq4C.png
http://i.imgur.com/0Vokq4C.png
Or just use snoozing (I use mailbox) and this problem is solved. I could not go back to using a mail client that doesn't have this feature.
> 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.
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.
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:[email protected] 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.
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:[email protected] 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.
I'm awful at remembering to do anything. When doing inbox zero, I find it really useful to be able to postpone emails so I get a push notification on my phone when they come back into my inbox. That way I know if there is anything in my inbox, I should look at it pretty soon to decide how to process it (deal with it or postpone it)
Agressive archiving and postponing emails aren't mutually exclusive. They complement each other really well.
[edit] It also reduces stress. Some things can be dealt with until the evening, or tomorrow, or the weekend. It's really nice not having to pick though a middle of things that need to be done later and now and be constantly reminded that there's all these things to do. Of course, you can tag them or put them in folders, but it's nice when those tags/folders then let you know they're due.
Agressive archiving and postponing emails aren't mutually exclusive. They complement each other really well.
[edit] It also reduces stress. Some things can be dealt with until the evening, or tomorrow, or the weekend. It's really nice not having to pick though a middle of things that need to be done later and now and be constantly reminded that there's all these things to do. Of course, you can tag them or put them in folders, but it's nice when those tags/folders then let you know they're due.
Yeah, I do hardcore archiving and practice inbox 0 as much as possible, and it does alleviate that need. But it's still nice to have the email be at the top just when I get home.
Yes, that is the traditional inbox zero method. Snoozing is just a tweak to make it easier to get back to zero at the end of each day.
In that case, I'm using Google now on my phone and saying "remind me to look up XYZ at home". And then I get a popup reminder when home.
I've been trying to just keep my inbox clean, with varying degrees of success. I could see how snoozing would be useful too.
I've been trying to just keep my inbox clean, with varying degrees of success. I could see how snoozing would be useful too.
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.
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
I built a repository like Evernote where you can email and text your content for saving. Butternote.com
> 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.
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...
> "... 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.
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.
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.
omg yes.
We're working on making all of our features togglable. Stay tuned.
We're working on making all of our features togglable. Stay tuned.
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
If it's useful to anyone: http://pastebin.com/c4JvjNef
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...
Cool. Thanks. That's nicer than what I did!
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
Pic: https://www.streak.com/images/snooze/snoozeCompose.png
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!
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.
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.
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?
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.
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.
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.
If we instead just replied to the thread, we could probably get away with just read permissions.
Is it possible to have full read/write permission but no communication with the outside world?
Presumably, this would involve denying the ability to send emails and denying various forms of network access.
Presumably, this would involve denying the ability to send emails and denying various forms of network access.
The API that launched today is just a backend API, so by definition your email data is accessible to the application on their servers.
You may be confusing how Streak works, where we have a browser extension that runs inside your browser, but our backend is the one doing the snoozing.
You may be confusing how Streak works, where we have a browser extension that runs inside your browser, but our backend is the one doing the snoozing.
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.
You mean "read receipts" which have been around for decades?
And can be bypassed in most standalone clients
Feedback: your snoozing feature is confusing because it overlaps with your reminders. Should I use reminder or snooze?
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.
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.
Is your app similar to Boomerang? If so I will check it out more
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.
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.
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.
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.
> 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.
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.
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.
Unsuited in what way? Can you go into more detail?
Because only Microsoft gets hate on HN.
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.
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.
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.
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.
> 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.
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.
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.
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 ?
Is it to bypass firewalls in some way ?
Email allows someone to send me data, as opposed to HTTP/S which targets servers. Adding structured data to emails could allow natural language communication to have a machine readable view of the communication. And there's probably a lot more uses.
You'd still have the option to use WebSockets or Ajax-polling.
I've seen an application in production using e-mails as a message broker.
It worked pretty well.
It worked pretty well.
I've done that twice: First time was when we built a demo registrar platform for ".name". We used Qmail with some custom bits and pieces to distribute messages that were used for things like live updates of the primary DNS server, live updates for a web forwarding service etc. A couple of the guys took the idea much further, and implemented a small library to do things like queue browsing via POP3.
The nice thing was all the existing tools that works well with various aspects of e-mail, and the great ease of introspection and testing.
The second time I did it was at Edgeio, where I initially used it to get a prototype of our blog feed retrieval / indexing pipeline up and running quickly. Though we relatively soon replaced it with a homegrown Stomp server, mostly because a lot of the stuff we were doing didn't need the delivery guarantees of e-mail, so we used in-memory queues for a lot of stuff.
It works great for some workloads, and it's a very easy way of prototyping things that makes it easy to debug message flows etc.. The state of open source message brokers have drastically improved since the times I did it, though - the first time we did it was back in 2002 or 2003.
The nice thing was all the existing tools that works well with various aspects of e-mail, and the great ease of introspection and testing.
The second time I did it was at Edgeio, where I initially used it to get a prototype of our blog feed retrieval / indexing pipeline up and running quickly. Though we relatively soon replaced it with a homegrown Stomp server, mostly because a lot of the stuff we were doing didn't need the delivery guarantees of e-mail, so we used in-memory queues for a lot of stuff.
It works great for some workloads, and it's a very easy way of prototyping things that makes it easy to debug message flows etc.. The state of open source message brokers have drastically improved since the times I did it, though - the first time we did it was back in 2002 or 2003.
Isn't there a lot more overhead with the headers? Neat idea though.
Depends on your messaging volume and typical message size. For some types of apps it won't matter because the volume is small; for others it won't matter because the payload is huge. But you get battle-tested federation, scaling, server discovery etc. nearly free.
You can still replicate Active Directory over SMTP.
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.)
I don't think IMAP support is going away. This is just a better API for devs to create apps for Gmail.
I think its pragmatic, IMAP is just so painful.
EDIT: and inefficient
EDIT: and inefficient
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.
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?
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?
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.
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.
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.
You could label it "NSA access".
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.
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
[1] https://developers.google.com/gmail/api/auth/scopes
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.
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.
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.
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.
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.
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.
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.
This was the reason Google provided for not supporting Git in Google Code initially. They do support git now though.
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.
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.
Google IMAP has extensions for single sign-on using OAUTH, see https://developers.google.com/gmail/xoauth2_protocol
Yep, was hoping for more fine-grained control for reading, not just 'read everything'
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.
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.
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.
Can you send mail over IMAP?
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/
"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/
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.
> LinkedIn definitely made me skeptical on allowing even trustworthy-seeming companies access to my contacts.
Trustworthy-seeming companies like, say, Google?
Trustworthy-seeming companies like, say, Google?
Do you not give any applications IMAP access to your email?
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.
Everyone's fine with the former, but the second should always give people the creeps.
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.
It would be sweet if email, in general, was just a nice RESTful API.
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...
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).
It's not REST but it's an HTTP API proposal: http://jmap.io/
would be curious to hear some of the things you have in mind?
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..
Until then I'll probably run out of "quota units" polling the thing..
You could probably have your mail pass through a non-gmail server like http://www.mailgun.com/ first
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.
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.
you've just successfully invented PagerDuty (albeit cheaper and DIYed) ;)
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.
The quotas are per user. So you can poll the /history endpoint per user. But yes, this isn't very efficient.
You could use Zapier: https://zapier.com
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.
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.
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
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
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.
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.
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.
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.
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.
This sort of thing is already possible – anyone can add GMail actions and cards to their messages: https://developers.google.com/gmail/actions/overview
Can't wait for the Emacs Lisp client library! (Wish I had time to work on that.)
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?
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?
[deleted]
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.
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.
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.
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.
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...
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.
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.
Wy don't they make an open standard RESTful API which would be used across mail providers, just like IMAP?
Sadly, the API doesn't support search, which makes it extremely limited for all but trivial apps.
it does support search
EDIT: see https://developers.google.com/gmail/api/v1/reference/users/t... and look at the 'q' parameter
EDIT: see https://developers.google.com/gmail/api/v1/reference/users/t... and look at the 'q' parameter
I stand happily corrected.
Does this help with getting the new Gmail Inbox in the IMAP clients?
The API Overview link is dead. I expect better.
GMail desktop client? Yes please :)
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.
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?
What is it that you want that a desktop mail client like Outlook or Thunderbird doesn't give you?
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.
How do you add google-api-services-gmail-v1-[version].jar to your classpath?? Where is this file?
Here is the actual Google blog post: http://googleappsdeveloper.blogspot.com.ar/2014/06/introduci...
The article is light on the technical details.
Here's the API: https://developers.google.com/gmail/api/
We changed the url from http://online.wsj.com/news/article_email/google-opens-gmail-....
Was I the only one who thought for a moment this was another privacy related story (opening my email!)
Yes, yes you were.
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
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.