Hacker News Reader

Comment by rbinv | Hacker News Reader

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?

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.

Thanks for elaborating. CRM does indeed seem like a good fit.

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.

Or Use Gmail's REST API if you use Gmail/Google Apps:

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

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

(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

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.

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.

Helpdesk/support applications would need this too to automatically create tickets, update status, send your answer, etc.

A CRM platform? An automated billing API? Every possible API?

Reply on news.ycombinator.com