Open-source client scaffolds and API pricing(inboxapp.com)
inboxapp.com
Open-source client scaffolds and API pricing
https://www.inboxapp.com/blog/clients-and-pricing
19 comments
I'm in Inbox employee. I'd be glad to answering questions about what we do, our platform and the rest.
Inbox seems like a great product.
I am building this desktop productivity tool which helps you to stay on top of things that matter most to you - www.StayOnTop.co
Do you have features which can help me do following operations -
1. Knowing whether user had read his email.
2. Downloading email attachments
3. Search\find inside email using regex or some keywords
4. How much time it takes to download first 50 emails?
5. How much times it takes for authentication and for how long the session token will be valid?
6. Do you support paging of emails? Like page 1, page 2....n
Much Thanks.
I am building this desktop productivity tool which helps you to stay on top of things that matter most to you - www.StayOnTop.co
Do you have features which can help me do following operations -
1. Knowing whether user had read his email.
2. Downloading email attachments
3. Search\find inside email using regex or some keywords
4. How much time it takes to download first 50 emails?
5. How much times it takes for authentication and for how long the session token will be valid?
6. Do you support paging of emails? Like page 1, page 2....n
Much Thanks.
Some quick replies: (I work at Inbox.)
1. Yes, we expose unread state via the tags endpoint.
2. Yes, check out the files endpoint
3. Currently we have filtering on subject line, and we're working on full-text body search. (It's hard.)
4. Depends on the size of the emails. In general less than a minute.
5. Our OAuth flow is super quick. Access tokens are valid forever unless the user or developer revokes them.
6. Yes, see the `offset` and `limit` filter parameters, which let you page nearly any API query.
1. Yes, we expose unread state via the tags endpoint.
2. Yes, check out the files endpoint
3. Currently we have filtering on subject line, and we're working on full-text body search. (It's hard.)
4. Depends on the size of the emails. In general less than a minute.
5. Our OAuth flow is super quick. Access tokens are valid forever unless the user or developer revokes them.
6. Yes, see the `offset` and `limit` filter parameters, which let you page nearly any API query.
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?
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.
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.
Having said that, IMAP libraries are good enough to not have to pay for a wrapper when using most email providers.
(I work at Inbox.)
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
IMAP libraries are good enough to not have to pay for
a wrapper when using most email providers
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
Or Use Gmail's REST API if you use Gmail/Google Apps:
https://developers.google.com/gmail/api/
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
https://www.inboxapp.com/features
Plus, the Inbox sync engine is open source.
https://github.com/inboxapp/inbox
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.
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.
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.
How would you compare Inbox to Context.IO from a REST API functionality perspective and overall goals?
Seems very similar to me - except Context.IO is either free or $0.05 / month / mailbox.
Seems very similar to me - except Context.IO is either free or $0.05 / month / mailbox.
[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!
Two big things:
• 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.
See the bottom of this page for more info: https://www.inboxapp.com/pricing
• 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.
See the bottom of this page for more info: https://www.inboxapp.com/pricing