5 ms·

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

by 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/
  - grinich 12y ago
    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
- grinich 12y ago
  (I work at Inbox.) 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. [0] https://www.inboxapp.com/docs/api#files https://www.inboxapp.com/docs/api#files [1] https://www.inboxapp.com/docs/api#threads https://www.inboxapp.com/docs/api#threads
opendais 12y ago
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.
- grinich 12y ago
  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.

by 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/
- grinich 12y ago
  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
grinich 12y ago
(I work at Inbox.) 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. [0] https://www.inboxapp.com/docs/api#files https://www.inboxapp.com/docs/api#files [1] https://www.inboxapp.com/docs/api#threads https://www.inboxapp.com/docs/api#threads

opendais 12y ago

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.

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