News for hackers. Stuff that matters.
Re:Open-source client scaffolds and API pricing by rbinv on Wednesday October 01, 2014 @11:57AM (#8395447)
So basically it's a REST/HTTP wrapper for IMAP?

Also (and I'm serious): Why would any app (that is not an email client) need to directly access a user's emails?

Re:Open-source client scaffolds and API pricing by vorador on Wednesday October 01, 2014 @12:01PM (#8395479)
Some of our customers use it for CRM -- this way they can automatically import informations about your leads directly into their system.

Also, we're not simply a REST wrapper for IMAP. We sync contacts and calendars too. We also support Exchange syncing which is something else altogether.

Re:Open-source client scaffolds and API pricing by rbinv on Wednesday October 01, 2014 @12:04PM (#8395508)
Thanks for elaborating. CRM does indeed seem like a good fit.
Re:Open-source client scaffolds and API pricing by IgorPartola on Wednesday October 01, 2014 @12:26PM (#8395670)
ITTT type applications could also benefit from this. Year ago I wrote a script that would send me a digest every morning that would include things like a list of cron jobs that ran last night. To do that I had the cron jobs email a specific mailbox as the last step, and had my script connect via IMAP to check them.

Having said that, IMAP libraries are good enough to not have to pay for a wrapper when using most email providers.

Re:Open-source client scaffolds and API pricing by grinich on Wednesday October 01, 2014 @01:27PM (#8396158)
(I work at Inbox.)

    IMAP libraries are good enough to not have to pay for 
    a wrapper when using most email providers
I found this actually not to be true when building my own stuff. Although IMAP is a "standard," the various different extensions and quirks mean you need to essentially build for each provider initially.

There's also a lot of stuff in Inbox API does that's not available in IMAP. Like the files endpoint[0], or threads as a first-class object[1].

Plus, you don't need to worry about MIME or character encodings with Inbox. The reason we don't great email tools is that they're hard to build.

[0] https://www.inboxapp.com/docs/api#files

[1] https://www.inboxapp.com/docs/api#threads

Re:Open-source client scaffolds and API pricing by toomuchtodo on Wednesday October 01, 2014 @12:57PM (#8395947)
Or Use Gmail's REST API if you use Gmail/Google Apps:

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

Re:Open-source client scaffolds and API pricing by grinich on Wednesday October 01, 2014 @01:35PM (#8396234)
The Gmail API is great, but if you're building a real app that needs more compatibility, Inbox is a much better fit.

https://www.inboxapp.com/features

Plus, the Inbox sync engine is open source.

https://github.com/inboxapp/inbox

Re:Open-source client scaffolds and API pricing by opendais on Wednesday October 01, 2014 @12:31PM (#8395720)
Automated processing for CRMs, Customer Service, scheduling, alerting [PagerDuty!], etc. generally.

Tbh, I'd use something like Mandrill if I was trying to automate things using 3rd party delivery/integration.

Re:Open-source client scaffolds and API pricing by grinich on Wednesday October 01, 2014 @12:42PM (#8395821)
Where the Inbox API really shines is when you want to build an app that pulls alerts, sales leads, tickets, etc. out of someones mailbox.

It's the other side of the puzzle.

Re:Open-source client scaffolds and API pricing by koopajah on Wednesday October 01, 2014 @12:23PM (#8395654)
Helpdesk/support applications would need this too to automatically create tickets, update status, send your answer, etc.
Re:Open-source client scaffolds and API pricing by Cynddl on Wednesday October 01, 2014 @11:59AM (#8395468)
A CRM platform? An automated billing API? Every possible API?