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.
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.
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.
[Disclaimer: I'm Dan, Context.IO's product manager]
We welcome InboxApp to the email API space. Like Context.IO, they see the value of helping developers build apps that interact with email. Building a platform like Context.IO, that abstracts complex systems, involves more technical challenges and product-level decisions, than you can keep track of. So, it’s not a surprise that our two teams came to different conclusions and have built somewhat different solutions. InboxApp made a choice to cache 100% of the email data, hoping to solve potential availability issues, which is key for some use cases. As a result, developers on that platform need to cover the costs for storing that data, whether or not they need it. We've worked with and spoken to hundreds of developers over the last few years and learned that the vast majority don't need that model and do not want to carry those costs. In the few cases where the dev needs a cache of every single message, many decide to store the data they need, instead of relying on a third party to store everything in their users’ mailbox.
If speed is the utmost concern and you are able to charge your users enough for your product to cover the cost of the platform while keeping your business afloat, then paying $5 a month per account might be cost-effective. However, if you prefer to use a header caching layer and you can engineer around caching the bodies, then using Context.IO for free is a better fit.
Just a couple quick points I should mention. Context.IO stores all of the message headers in our caching layer. Combined with our webhooks, applications are quickly notified of a change and can easily retrieve messages they care about. Exchange support is being used by initial beta testers on our Lite API right now. If you're interested in joining the beta test, please let us know!
• The Inbox Platform isn't a proxy later. It actually maintains a full mail sync, so response times are super fast. Context.IO is ridiculously slow (like 10-30 sec).
• Support for Exchange ActiveSync. They've been promising this for years, but haven't delivered it.
We also have client scaffolds, modern SDKs, a platform that deals with MIME, character encodings, and more. You get what you pay for here, and it's an actual platform that you can build an app on. Many of our customers have switched from Context.IO.
