Privacy Policy
PDFCraft is an HTML-to-PDF API. It exists to turn documents you send into PDFs and hand them back. This page says exactly what that involves for your data, in the order you would actually want to know it.
Effective 1 September 2026
Who runs this service
PDFCraft is operated by Gaurav Singh, an individual sole proprietor, from:
Raj Nagar Extension
India
For anything on this page — a question, an access request, a deletion request, a complaint — write to support@pdfcraft.dev. That address is monitored by a person, and it is the fastest route to a real answer.
The distinction that matters most
There are two different kinds of data here and PDFCraft stands in a different relationship to each. Getting this the wrong way round is how privacy policies become misleading.
| Data | Our role | Means |
|---|---|---|
| Your account — email, plan, API keys, usage counts, billing history | Controller | We decide what to collect and why. This page governs it. |
| The documents you render — the HTML or URL you send us, and anything inside it | Processor | You decide what to send. We only do what you asked, for as long as it takes, then delete it. If that content includes other people’s personal data, you are their controller and our Data Processing Addendum applies. |
What we collect
Because you have an account
- Your email address. Required — it is how you sign in. There is no password: we email you a one-time link.
- Your API keys, hashed. We store a one-way hash and the first few characters so you can tell your keys apart. We cannot recover a key and neither can anyone who steals our database.
- Render metadata. For each render: an id, whether the input was HTML or a URL, the output size in bytes, the page count, how long it took, and an error code if it failed. Not the document itself. This is what your usage page and your invoice are built from.
- Sign-in sessions, in Redis, expiring automatically.
Because a server has to answer a request
- IP addresses, in web-server access logs. We also use the IP of anyone using the public playground key to enforce its cap of a few renders per hour, so one visitor cannot exhaust it for everybody.
- Standard request lines — timestamp, path, status code, user agent.
What we deliberately do not collect
- No card details, ever. Payments run entirely through Dodo Payments, who is the merchant of record and the name on your statement. Your card number never reaches our servers. We receive a customer reference, a plan, and a subscription status.
- No analytics, no advertising, no third-party trackers, no cookie banner. The documentation site is static HTML served off disk. The only cookie PDFCraft sets is the one that keeps you signed in to your dashboard, and it is strictly necessary, so there is nothing to consent to.
- No copies of your documents for training, sampling, or quality review. Nobody reads what you render.
What happens to a document you send
This is the part worth reading closely, because it is the honest version rather than the reassuring one.
- Synchronous renders (
POST /v1/render) hold your HTML in server memory only. A fresh browser context opens, renders it, and is destroyed. Nothing touches disk unless you asked for"output": "url". - Asynchronous renders (
POST /v1/render/async) must survive a restart, so the job — including your HTML, and including anyheadersorcookiesyou passed for an authenticated URL — is written to our Redis queue. A successful job is discarded within an hour. A failed job is retained longer so we can retry it and so you can see why it failed. If that is not acceptable for a particular document, use the synchronous endpoint. - The finished PDF, when you ask for a URL rather than bytes, is written to object storage and reachable only through a signed, expiring link. 24 hours from the moment it is created, then permanently deleted. There is no way to extend that, and no archive.
How long we keep things
| Data | Kept for |
|---|---|
| A rendered PDF | 24 hours from the moment it is created, then permanently deleted |
| The document you sent | Not kept at all for synchronous renders. For asynchronous renders, only as long as the queue job lives — about an hour after success, longer after a failure |
| Render records | metadata only (id, size, page count, duration, error code) kept for billing history |
| Account data | for as long as the account exists, then 90 days after closure |
| Server logs | 30 days |
Why we are allowed to hold it
If you are in the UK or the European Economic Area, the UK GDPR and the EU GDPR give us six possible legal bases and we rely on three:
- Performance of a contract (Article 6(1)(b)) — your email, keys, renders and usage counts. Without these there is no service.
- Legitimate interests (Article 6(1)(f)) — access logs and the playground’s per-IP cap, for security, abuse prevention and keeping the service up. We have weighed this against your interests and consider it proportionate; you can object at any time using the address above.
- Legal obligation (Article 6(1)(c)) — retaining billing records where tax law requires it.
We do not rely on consent for anything, because we do not do anything that needs it. We send no marketing email.
Who else can touch it
Four companies, listed with what each one is for. We do not sell data, share it with advertisers, or move it to anyone not on this list.
| Company | What for | Where |
|---|---|---|
| Hetzner Online GmbH | Servers that run the API and the render engine | Germany (EU) |
| Cloudflare, Inc. | Object storage for rendered PDFs (R2), DNS | EU-hosted bucket; company registered in the United States |
| Resend, Inc. | Sign-in links and account email | United States |
| Dodo Payments | Payment processing and merchant of record | Per their own terms |
If this list changes we will update this page before the change takes effect. Customers with a Data Processing Addendum in place get notice and a window to object.
Where your data physically is
Your documents and your database records live on servers in Germany. That is deliberate: it means personal data belonging to people in the EU or UK stays inside the EEA for storage and processing, and no transfer out of it is needed to run the service.
The operator administers those servers remotely from India, and account email is delivered through a provider in the United States. Neither country has an EU adequacy decision, so where those transfers involve personal data we rely on the European Commission’s Standard Contractual Clauses together with technical measures — encryption in transit, key-based access only, and no bulk export of customer content. We will provide the relevant clauses on request.
What you can make us do
Regardless of where you live, you can ask us to:
- tell you what we hold about you, and give you a copy
- correct anything wrong
- delete your account and everything attached to it
- export your data in a machine-readable form
- stop relying on legitimate interests, or restrict what we do while we look into it
Email support@pdfcraft.dev. We answer within 30 days and usually much faster — this is a one-person operation, not a ticket queue. We will not charge you and will not ask why.
If you are in the EEA or UK and we handle it badly, you can complain to your national data protection authority; you do not need our permission and you do not have to come to us first. If you are in India, the Digital Personal Data Protection Act gives you comparable rights including access, correction, erasure and the right to nominate someone to exercise them if you cannot; the same email address is our grievance-redressal contact.
Security, stated plainly
- TLS on everything. Plain HTTP redirects.
- API keys stored as one-way hashes, never in plaintext, never recoverable.
- Each render runs in a fresh, isolated browser context that is destroyed afterwards. One customer’s document cannot see another’s.
- The database and cache are not reachable from the internet at all.
- Rendered PDFs are only ever reachable through a signed link that expires.
No service can promise it will never be breached, and we are not going to pretend otherwise. If we suffer a breach affecting your personal data we will tell you and the relevant authority without undue delay, and within 72 hours where the GDPR requires it.
Children
PDFCraft is a developer tool sold to businesses and developers. It is not directed at children and we do not knowingly collect data from anyone under 18. If you believe a child has created an account, write to us and we will delete it.
Changes to this page
We will post a new effective date here, and email account holders before any change that reduces your rights or widens what we collect. Continuing to use the API after a change means you accept it; if you do not, close your account and we will refund the unused part of a prepaid period.
Governing law
This policy is governed by the laws of India and disputes go to the courts at Ghaziabad, Uttar Pradesh, India. Nothing here removes a right you have under the mandatory law of your own country, including the GDPR rights described above.