A PDF API that writes to your own S3 bucket

The first question a security review asks about a document vendor is where the documents end up. For most of this category the honest answer is: on the vendor's servers, for as long as their plan says.

The problem with the usual answer

Documents are rarely boring. They are invoices with bank details, certificates with names, contracts with terms, statements with balances. Handing that to a third party to store is the part of an integration that stalls in legal review, and no amount of encryption-at-rest wording makes the question go away, because the question is not "is it encrypted", it is "who holds it".

We render and write. We do not keep.

On Growth and Enterprise the finished PDF is written directly into storage you own, encrypted with your own key. There is no copy on our side to retain, expire or leak, and no dashboard of ours where your documents can be browsed.

What we hold, which is almost nothing

We store your templates, because they are the product you are building. We store counts of documents rendered, because that is how billing works. The JSON you send to be merged is held in memory for the render and not written down. The document itself goes to you.

The credential position matters as much as the storage one. On AWS we hold no key, only permission to assume a role you control. On Azure we hold no secret at all — the federation is signed with a key that lives in a hardware security module and cannot be exported.

What this is worth in a security review

It changes the shape of the conversation. "Where does our data live" stops being a vendor question and becomes an answer you already have, because it lives where the rest of your data lives, under the controls you already run. Paperomat holds no SOC 2 certification and says so plainly — the architecture is the argument, not a badge.