
Open-source client scaffolds and API pricing - Artemis2
https://www.inboxapp.com/blog/clients-and-pricing
======
vorador
I'm in Inbox employee. I'd be glad to answering questions about what we do,
our platform and the rest.

~~~
mandeepj
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
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
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?

~~~
IgorPartola
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
Or Use Gmail's REST API if you use Gmail/Google Apps:

[https://developers.google.com/gmail/api/](https://developers.google.com/gmail/api/)

~~~
grinich
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](https://www.inboxapp.com/features)

Plus, the Inbox sync engine is open source.

[https://github.com/inboxapp/inbox](https://github.com/inboxapp/inbox)

------
jon_wu
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.

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

