4 ms·

Open-source client scaffolds and API pricing

46 points by Artemis2 12y ago

vorador 12y ago
I'm in Inbox employee. I'd be glad to answering questions about what we do, our platform and the rest.
- mandeepj 12y ago
  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.
  - grinich 12y ago
    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.
rbinv 12y ago
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?
- Cynddl 12y ago
  A CRM platform? An automated billing API? Every possible API?
  - deleted 12y ago
    [deleted]
- vorador 12y ago
  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.
  - rbinv 12y ago
    Thanks for elaborating. CRM does indeed seem like a good fit.
- koopajah 12y ago
  Helpdesk/support applications would need this too to automatically create tickets, update status, send your answer, etc.
- IgorPartola 12y ago
  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.
  - toomuchtodo 12y ago
    Or Use Gmail's REST API if you use Gmail/Google Apps: https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/
jezell 12y ago
$5 per month per account. Same price as an entire Office 365 subscription for an API that can talk to your Office 356 subscription. Interesting idea, but your pricing is insane.
jon_wu 12y ago
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.
- grinich 12y ago
  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 https://www.inboxapp.com/pricing
- dpcorbin 12y ago
  [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!

46 points by Artemis2 12y ago

vorador 12y ago

I'm in Inbox employee. I'd be glad to answering questions about what we do, our platform and the rest.

mandeepj 12y ago
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.
- grinich 12y ago
  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.

rbinv 12y ago

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?

Cynddl 12y ago
A CRM platform? An automated billing API? Every possible API?
- deleted 12y ago
  [deleted]
vorador 12y ago
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.
- rbinv 12y ago
  Thanks for elaborating. CRM does indeed seem like a good fit.
koopajah 12y ago
Helpdesk/support applications would need this too to automatically create tickets, update status, send your answer, etc.
IgorPartola 12y ago
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.
- toomuchtodo 12y ago
  Or Use Gmail's REST API if you use Gmail/Google Apps: https://developers.google.com/gmail/api/ https://developers.google.com/gmail/api/

jezell 12y ago

$5 per month per account. Same price as an entire Office 365 subscription for an API that can talk to your Office 356 subscription. Interesting idea, but your pricing is insane.

jon_wu 12y ago

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.

grinich 12y ago
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 https://www.inboxapp.com/pricing
dpcorbin 12y ago
[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!