Show HN: PDF Otter – Fill in PDFs Online and API
pdfotter.com
pdfotter.com
The biggest thing that costs us time is schema validation. We ended up building a tool that rejects uploads if the text fields don't match, or if you forget to include a radio option, etc. It also has "recommended" fields which issue warnings if they are not implemented.
Radio options, checkboxes, and images (for signatures) would be a welcome addition that I didn't see in the editor.
The documentation / online demo doesn't make it clear how I would go from fields -> API access (because how do I name the fields?).
[append]
An API endpoint to get the unfilled PDF template would also be good, especially if bundled with a client library that handled the call to pdftk. Some of our documents are HIPAA and I don't want to deal with having the client data leave our machines.
The PDF Otter API powers the PDF editor advertised on the homepage. The editor is simple but I think its better than similar services because you don't need to sign up/pay to fill-in and download your PDF. I think there's a lot of potential out there for apps built on the API. Feel free to reach out to me at mariusz [at] pdfotter [dot] com if you have any questions or ideas!
A signature pad could work too; I think HelloSign has something like that. But it's not a great solution if you don't have a tablet, since it's really hard to draw a proper signature with a mouse. Honestly, even just adding a "handwriting font" might be good enough for most circumstances. Most of the document signing services provide this, and it could be implemented very quickly with minimal changes to your API.
If I were you, I would probably start with a handwriting font, and add hand-drawn signature support afterward. I would also look into what the law says about this sort of thing. I know that services like HelloSign require that you authorize them to use your signature in a legally-binding manner. But I don't know if that regulation would apply to your service, since your service is a lot more bare-bones. For example, you don't store the PDFs indefinitely, and you don't coordinate any sort of multi-party signature operation; that all happens out-of-band. So you might be in the clear.
That so many governments use, and insist their citizens use PDFs, it's really not OK for us to have to depend on proprietary closed source software. I have zero problem with making a profit on great tools and infrastructure and services, but the foundation needs to be owned by the public.
Actually, add a paid tier below that, 500 PDFs/m for $55.
No privacy policy. Nothing except "we delete your PDFs after 24 hours".
No security guarantee.
No performance bond.
(Do I expect that for free? No. But I expect the documentation to be there.)
Lots of small law offices, insurance agencies, etc. that I bet you could get using it.
Would also recommend lowering the free # of API usages to ~100 or something :)
Also being able to preview text settings as you create templates would be nice.
You could add alignment tools for multiple fields - look at Inkscape for inspiration.
I've tested the editor again because a 1cm offset is unacceptable. It looks like the field boxes (the transparent blue or orange rectangles you can drag and resize) appear in the correct spots on the PDF. If the text is too large to fit in the rectangle, we shrink it to fit. What might be going on is my backend is in disagreement with the frontend about what font size to use if we need to shrink the text. Then a larger than normal offset could appear on the right-hand side of the text. I'm working on fixing that. But rest assured that the field boxes are put in the correct place on the PDF.