I built something like this to scratch an itch at Zapier (both personally and for a few of our customers). I've mulled over releasing it someday for fun. This is a real need because (frighteningly?) a majority of the business world runs on:
* Generated emails
The concept is great though. The landing page is wonderful. Simple, to the point, decent use cases, inside the app has a nice onboarding and great options around exporting, etc... I really dig it.
Best of luck guys!
thanks a lot for testing it and giving some feedback! I really appreciate it.
The whole idea is based on exactly the assumption you mentioned: there are a lot of businesses who are stuck with clunky workflows of copy&pasting data. But who do I tell, you know that.
Regarding your issue with the extractor UI: Your screenshot is showing the second out of three steps. The purpose of this step is to refine the data selected in the first step. If you are sending html emails (with dom elements like h1, links, tables etc.) you can directly select the data in the first step with your mouse. So you don't need to refine the whole email body in the second step.
I might very well be wrong too, it wouldn't be the first time!
Add fields, highlight parts of your email, fields are mapped!
* Vanilla Postfix
* A user with a .forward file, calling curl to post the email to my receiver route on my app
* A receiver in my Go app using the inbuilt mail package
* Logic to recursively parse multipart emails to extract plain text where possible, or strip tags from HTML when there is no text/plain version
I've been amazed at the performance and the reliability of it even in staging. It automatically emails back a confirmation of the commands and the confirmation comes back lightning quick, back through the Postfix server.
Anyone considering creating their own inbound email handler shouldn't be scared to have a crack, I was amazed at how simple and rewarding it was.
You get all sorts of goodies like nice attachment handling and automatic stripping out of quoted text which aren't exactly hard but fiddly.
The interest for attackers isn't as high as something like LastPass, but at a bare minimum a successful hack will come back with a big list of valid email addresses and companies they have relationships with -- which would be very valuable to someone interested in spoofing, for example.
And that's assuming that the people/person behind mailparser.io are honest.
It depends on what kind of data your clients might want to handle in email workflow, but I imagine most businesses will be wary of passing off potentially sensitive material to an outside party that they don't trust. Things like "first month free" don't address this -- the fear isn't "we'll try this service and it won't work for us, and our money will be wasted", it's "we'll try this service, and an employee or hacker will sell our data to competitors, spam/upsell our customers, sell our contact lists...".
Obviously these aren't the most likely scenarios, but it's a bit like hiring a new employee who will be working completely without oversight with your company data... You'd want to put serious time into interviews, checking references, etc..
The site as-is: as far as I can tell, there are no human beings behind the site, or any established company. There's no phone number or address. It's not even clear what country (and hence legal jurisdiction) the business is operating in.
I don't mean to come off as too negative -- there are still companies that will not have a problem with the risks (and/or for whom the risks will be minimal), but you'll cast a wider net with a more solid presence.
To answer your question meanwhile: mailgun provides an API for developers who want to route incoming emails to their app. mailparser.io however tries to target the tech-savvy businness owner who wants to automate his email workflow, notable who wants to extract data from repetive automated emails. We see mailparser.io more in the corner of zapier and ifttt.
They offer an inbound feature which isn't emphasized!
Carousels are bad. Stop using them.