Your team designs the document.
Your code sends the data.
Your customer gets the PDF.
Whoever owns how an invoice looks builds it in a browser editor and changes it whenever they like. Your application posts JSON and gets a PDF back. Nobody files a ticket to move a logo.
<p>Billed to {{.Customer.Name}}</p>
<table>
{{range .Lines}}
<tr>
<td>{{.Item}}</td>
<td>{{.Amount}}</td>
</tr>
{{end}}
</table>
How it works
Three steps. A developer is needed for exactly one of them.
Design the document
Build the layout in the browser and drop placeholders where the data belongs. The PDF preview re-renders as you type, so you are looking at the real output rather than an approximation of it.
Wire it up once
A developer creates a key and posts the data from your application. One request, one integration — and it does not need revisiting when the design changes.
Change it freely
Edit the template and every document rendered afterwards picks it up. No release, no code change, no waiting for someone else's sprint to end.
Built for two people
The person who cares how it looks isn't the person who ships it.
Most document APIs give you one tool: a template file in a repository. That makes every wording change a developer task. Renderpaper splits the work along the line it already falls on.
Owns what the document says
- Build and edit templates in the browser
- See the true PDF while editing, page breaks and all
- Try it against sample data before it goes live
- Change wording, logo or layout without asking anyone
Owns the integration, once
- One authenticated POST returns the PDF
- Reference a stored template by id, or send HTML inline
- Batch endpoint for invoice and statement runs
- No template files to maintain, review or redeploy
$ curl https://renderpaper.com/v1/templates/inv_8f2/render \ -H "X-API-Key: $RENDERPAPER_KEY" \ -d '{"data":{"Number":"2026-0142"}}' \ -o invoice.pdf # invoice.pdf — 1 page, A4
Proof
Don't take our word for the output.
This link renders an invoice through the same pipeline your account would use — right now, with no signup. Open it, zoom in, check the text is selectable and the accented characters are intact.
Pricing
Priced on documents, because that is what you are counting.
Every plan has the editor, the full API and the same 200-template ceiling. The tiers differ in volume alone. Go past it on a paid plan and extra documents are $4 per 1,000 — nothing stops halfway through a run.
- Browser editor and live preview
- Full API for single renders
- 200 templates
- Batch endpoint for document runs
- 200 templates, same as every plan
- Extra documents billed, never cut off
- Everything in Starter
- Higher place in the render queue
- Everything in Growth
- First place in the queue
- Direct line for support
Questions
What people ask first.
Does a developer have to be involved every time the template changes?
No, and that is the whole point. Your integration sends data to a template id. Whoever owns the document edits it in the browser and the next render uses the new version. No deploy, no code change, no coordination.
Do I have to use the editor?
No. Post HTML inline on every request and never open it, or manage templates entirely through the API. The editor exists for the people who would otherwise have to file a ticket.
Will my CSS actually work?
If it works in Chrome, it works here — the renderer is headless
Chromium, not a reimplementation of a subset. Grid, flexbox and @page
rules all behave, and your own @page rule takes precedence over the paper
option. One boundary: templates are self-contained — the renderer fetches nothing
over the network. Images you upload are inlined automatically at render time;
data: URIs work as-is; for type, use the built-in fonts or embed one as
@font-face with a data: source.
What happens when I go over my plan?
On a paid plan documents keep rendering and the extra is billed at $4 per 1,000 — a hard stop in the middle of an invoice run is a worse outcome for you than a small bill. On the free plan rendering stops at the allowance instead, because there is no card on file to bill the extra to. A render that fails is never counted.
How long do you keep the documents?
A single render is never stored: the PDF goes back in the response body and nothing is written down. Batch results are held long enough for you to fetch them and then deleted automatically.
Stop shipping code to change a footer.
50 documents a month, free and indefinite. No card, no sales call, no demo to sit through.