I also used to work at Gusto (a payroll company), and we had to fill out a lot of tax forms, which took a lot of work. I know this is something that many financial and legal startups have to do, so hopefully FormAPI can make this process a lot easier.
Let me know if you have any questions or feedback!
One question though: I assume that the automatic detection of form fields does not always work. Especially if the PDF does not exist in a “fillable" format. Am I right with that interpretation?
In the future we might implement OCR and machine learning to automatically detect fields in scanned or photographed PDFs. I think it could also be useful to build an index of fillable PDF forms (e.g. from the IRS and UCSIS), and then use those original fillable PDFs whenever we detect a matching scanned form. We might also build a public database of fillable forms.
But I don't want to build any of those features unless I have a customer who actually needs it. (Please send an email to email@example.com if this is something you would use!)
So, how similar is this to FDF? Does it use FDF under the hood? If not, what are the pros and cons of this over FDF?
I'm not sure about the pros and cons. If a customer needed to generate PDFs with data in the FDF format, then that's something that I would be happy to build.
Obviously you can start with the most basic things like name, address, birthdate, etc, but to the extent that you can capture data every time a user fills out a form it becomes akin to a field linking problem that you can generalize across users.
Obviously the privacy folks here will hate this idea, but a system that could fill out forms for you because it already knows most of the structured data about you would be amazing.
For example: suppose a customer with a workflow where the customer fills out a PDF form and emails the completed PDF to an externality (e.g. supplier, other department whose workflow they can't control, etc.). So you build a modern UX that uses the PDF API to fill out the PDF with the data from the UI, and then email the PDF to the externality, just like before, so that they're on-board with the new UX (since it doesn't affect them at all).
Once you build the new UX, you can then sit with your externality and figure out what they need in order to hook into the modern system. After all, they benefit from a single queryable source of truth, just like anybody else, and the customer is generating that source of truth when they put their info into the UI which ultimately emails the PDF. Once you build the UX for the externality, there's no need to retrain your original customers - they can keep using the modern UX you built for them before. All you have to do is update internally to make sure you're updating the sources the externality's UX expects, stop using the PDF API and emailing the results, and your migration is finished in a pretty simple way that is transparent to the customer.
I mean, please do it for immigration, that's a good deed.
But I think the money is in using this technology in order to build “fill-in wizards" for businesses, especially law firms and other "conservative", paper-driven industries.
For example, every time you visit Vietnam, you have to fill out this visa application form: https://app.formapi.io/templates/c59fc7c0cc4df684a13cf4d04e6... (That's a working example.)
I would love to be able to save my details and automatically fill out most of the fields in these forms.
I look forward to hearing your feedback!
My lawyer seem to have a really good system (probably white-labeled), but the pdf's it generates have issued with annotations. I have to print them using Acrobat otherwise checkboxes are sometimes missing and hidden annotations are visible.
(But if someone needs to generate a PDF that uses editable forms, then I can add support for that.)
Your lawyer's system sounds interesting, and I can relate to those rendering issues. PDFs are incredibly complex -
the PDF reference  has 1310 pages, and I've had to read a lot to understand things like fillable forms and transformation matrices. I ended up fixing a bug in a PDF library where all the PDFs from Google Chrome were flipped upside down - https://github.com/prawnpdf/prawn-templates/pull/20
That's actually a great idea. If anyone is looking for a cheaper alternative to Adobe LiveCycle Designer, you could use FormAPI to create fillable PDF forms. Please send us an email at firstname.lastname@example.org if that's something you would use. This feature would be available when you subscribe to our Starter plan, and you could create unlimited fillable PDFs.
I was tempted to wait even longer and redesign everything, but I want to make sure I'm building something that people need.
FormAPI is not PCI DSS Certified or HIPAA compliant.
You understand that the technical processing and transmission of the Service, including your Content, may be transferred unencrypted and involve (a) transmissions over various networks; and (b) changes to conform and adapt to technical requirements of connecting networks or devices.
Unfortunately, this is a service that sees the data being entered on the form. If it processed a blank PDF form and sent back something you ran locally to generate a filled-in form, that would be great. But as a service, it sees too much user data.
If anyone is interested in FormAPI, but requires PCI certification and HIPAA compliance, please send an email to email@example.com, and we'll let you know when we are ready. You can also send an email to firstname.lastname@example.org to inquire about on-site hosting.
I've also worked at companies where we built something similar in-house. So while this is a very niche product, I know there's a least a few developers out there who may find it useful.
Building something like this is also a great way to find new problems to solve. I think even if it's a niche idea or something you're not sure about, it's better to start building something than to wait for the perfect idea.
Ever notice most new health care provider visits still require a ton of paper work?
Use mobile app to take a picture of their arbitrary form, use OpenCV to interpret it as as real data structure, autofill it from a personal database, and print it out on one of those tiny portable printers, and hand it back to them.
To try and make it viral: When used to process a form, the app also generates a web site for that office. Then anyone can search for dr. lowtech’s office and use the site to form and print them at home before coming in.
Each printed form would have a header/footer asking the provider to register on the site, at which point it could become an official entry point into the system and leverage other efficiencies. Some hipaa stuff applies but nothing insurmountable.
I guess everyone else here also has 10 ideas a day pop into their head for a startup. So on to the next one...
I'm not saying that it's bad, but I think it's strongly worth your while A/B testing that idea because it's quite granular.
You may find that with just 3 plans you would leave less money on the table over time.
(Of course you would also have a "call for enterprise options" link.)
Another option is (and I did this with pluggio) is to let, say, 50 people in for a very low special price and then observe exactly how many api calls they make.
Then based of that data work out your usage bands and magic levers.
Also, I note your only magic lever is usage but I bet there are other levers you can use to get people from one plan to another.
Anyway, I hope this is useful feedback!
Great job on the site :)
Not trying to plug our co but its totally relevant here...we built a field detection algorithm to find the fields in any form. So you can drag n drop your doc and start filling it in and sign it within a couple of seconds. Feel free to check it out. Thanks guys! https://www.paperjet.com/
We are very serious about protecting PII. One of the ways we achieve that is by using battle-tested frameworks and libraries with the default settings (Rails and devise), and not writing our own code for crypto and security.
By default, we delete generated PDFs and any associated data after 7 days. This can be configured in the template settings , so you can make the retention period much shorter. You can also immediately delete any submitted data by making an API request . (Disclaimer: Data may be present in our automated database backups for up to 2 weeks.)
Finally, FormAPI is not open source, but we can provide a license for a self-hosted installation. For enterprise plans and on-site hosting, please contact: email@example.com
Problem is, everyone (from Equifax to Yahoo) says that. If I can't trust a huge multi-billion corporate, I would certainly be nervous about trusting a very new startup with much more than my email address.
I am planning to move my hosting to Aptible , and will become PCI certified and HIPAA compliant.
If anyone is interested in FormAPI, but requires PCI certification and HIPAA compliance, please send an email to firstname.lastname@example.org. We'll let you know when we are ready. You can also send an email to email@example.com to inquire about on-site hosting.
On the one hand, I understand the concerns about PII in your app.
On the other hand, I'd be willing to bet there are a ton of line-of-business apps that don't handle PII that could benefit from this (purchase orders, B2B shipping forms, etc.).
Unless you have investors, I would suggest waiting until you get >100 paying customers to find out whether you need to pay the premium for PCI/HIPAA hosting.
Was DocRaptor a big influence on how you priced it?
Shameless plug: I've also recently been working with PDFs - a PDF template creator and API  - but I have a different use case in mind.
Are you aware of https://www.docmosis.com/ ?
How do you compare to them?
The goal of FetchPDF was to let web applications give their users a way to create and edit PDF templates in the browser. e.g. to customise system templates for invoices, certificates etc.
I still have a lot of work to do to, it would seem.
I've been a happy customer of docmosis, but I'm still interested in using your service if it provides easier templating.
Send through an email to the support email address and I'll upgrade the trial and set an API key without you needing to put in billing details.
But be warned - it's still in MVP stage and may disappoint! (It also means that it's very receptive to feedback :)
The big selling point for me is that the template generation is right there. It is much easier to explain to people than saying: All right, so you download libre office, create a document, upload it here, name it like this or that...
FetchPDF looks great! Best of luck to you as well!
So the use case is you have a company that only accepts PDFs as an input and you have a digital data set that you need to get each individual row into one PDF?
How do you handle signatures?
Also I work at an accounting firm and we have a home grown solution that does precisely this for all of the standard IRS forms we fill out. For a larger firm like mine, we can afford to have someone code the solution in house, but for smaller firms or for in-house accounting departments, this could be worthwhile, depending on the price point.
That use case sounds right. I've mainly been thinking about tax and immigration forms, or filling out financial and legal documents, etc.
There's no special field type for signatures at the moment, but you can upload a signature image, or use a text field with a handwriting font (Dancing Script ).
I will probably add the signature_pad  library to the online forms in the near future, and will add a special "signature" type. There might also be a new flow where you can request a signature via the API, and we'll send an email to the person who needs to sign the document.
(I actually just need to get a few more customers first, so that I'm building something that people need.)
The libraries I use are: pdf-reader , prawn , prawn-templates , origami , qpdf , and pdftk .
There's a new PDF library for Ruby called hexapdf , and it looks really promising. I think it might even be able to replace all six of these libraries, but it's released under the AGPL license, and commercial licenses are not available yet.
acrobat FDF and Apache PDFBox provide something similar but are not declarative. i'd be interested in seeing an approach with mozilla/pdf.js ... though i'm not sure how usable it would be.
If you upload a scanned PDF (e.g. plain images), then you can add form fields in the template editor. If you upload a pdf with a fillable form, then we will automatically import all of the existing fields (and the imported fields can then be modified or removed.)
If I understand it, create an HTML form, submit to server, spit back PDF. This has been built into ColdFusion for about a decade, and it is trivial. [and I assume other server side software can do the same thing].
Aside from that, the bulk of the PDF Forms I download these days can already be filled out with Acrobat. I'm not sure what benefit you're offering me in time savings.
Or if I built a service for end-users to fill out and sign PDFs, I would create a separate website and use FormAPI to generate the PDFs. (I don't think I will do this, though.)
You're right that if you just need to fill in a single form, then there are easier ways to do that. (Even just using the Preview app on Mac).
I guess I'm not understanding the niche you fill.
Good luck with it, though.
Shameless plug: if you need the opposite, i.e. getting text/structured data out of filled PDF forms (or any kind of PDF document), feel free to contact me.
When generating a PDF via an API request, you can add an image field, and upload your user's signature as an image. You could also create a faux signature by using a text field with a handwriting font (The Dancing Script  font is available.)
This is a tool for developers to fill out PDFs, so in your own application you could use something like the signature_pad library , and then pass the signature images to FormAPI.