[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!
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!