One invoice template
The markup your billing screen renders is the markup that prints. No second layout in a drawing API, and no way for the on-screen invoice and the attached one to disagree.
Invoice PDF API
Send the invoice HTML your application renders and get back the PDF you send the customer. Correct page numbers, the paper size their country expects, a whole billing run in one submission, and the archived copy in storage you own.
Create a free accountRead the API docs
Rendering credits, August720.00
Additional sites45.00
Support retainer180.00
VAT at 20%189.00
Total due1,134.00
The billing run
Rendering a single invoice is a solved problem in any language. What breaks is the rest of it: four thousand documents on the first of the month, a layout that paginates differently once a customer has thirty line items, an archive somebody will ask you to produce in five years, and a download link that does not stream every byte through your application.
Renderwolf takes the HTML you already render and handles the run around it. Submit the cycle as a batch, take a webhook per document, deliver each one into your own bucket, and hand the customer a signed URL with an expiry you set.
POST /renderwolf/v1/pdf
Authorization: Bearer rw_live_...
{
"html": "<html>...invoice INV-1042...</html>",
"paper_format": "a4",
"print_background": true,
"margin": { "top": 18, "bottom": 18 },
"footer_html": "<div style='font-size:9px'>Page
<span class=pageNumber></span> of
<span class=totalPages></span></div>"
}Capabilities
Pagination, paper size, volume, custody and delivery: the five things that turn one document into a billing process.
The markup your billing screen renders is the markup that prints. No second layout in a drawing API, and no way for the on-screen invoice and the attached one to disagree.
Footer templates carry Chrome's pageNumber and totalPages, so a five-page invoice numbers itself rather than being counted by your code before it knows how it paginates.
Six paper sizes with per-side margins and a scale factor, so the same template serves a UK customer on A4 and a US one on Letter without a branch in your code.
Batches and asynchronous jobs render thousands of documents without holding a connection open, with a webhook when each one is ready.
Deliver straight to your own S3-compatible storage, so the copy you must keep for seven years sits in a bucket under your retention and access rules.
A signed render URL with an expiry lets the customer fetch the document directly, without your application streaming bytes or exposing a key.
Use cases
Anything your application already renders on screen and somebody expects to arrive as a file.
Render the document from the same template and data your billing screen uses, at the moment you issue it.
Submit the whole cycle as a batch overnight and take a webhook as each document lands in your bucket.
Period statements and remittance advice from the same pipeline, with the paper size the recipient expects.
Attach a printable copy to the email your application already sends, produced from one request.
Outbound documents that need to look like the rest of your brand, without a word processor template nobody owns.
A signed URL per invoice, so a customer downloads any document from their account without a support request.
Invoices are one shape of a wider capability. The same endpoint prints statements, contracts, reports and certificates from the same markup you already maintain, and the guide walks through a working request with print backgrounds, headers and footers.
Pricing
Start with 250 free credits each month and no card required. Paid plans begin at £9 per month for 5,000 credits, shared across screenshots, PDFs, images and video. A customer downloading the same invoice again is a cache hit and costs nothing, failed work is refunded, and reaching a cap pauses rendering rather than billing overage.
Questions
The details that decide whether this fits, without reading the whole reference first.
No. Send the HTML your billing screen already renders. It is printed in a real browser, so the document the customer receives is the document you can see in your own application.
Supply footer HTML using Chrome's pageNumber and totalPages classes and it repeats on every sheet. Header and footer templates render in their own context and inherit nothing from the page, so set their font and size inside the template.
Yes. Submit them as a batch and poll the batch for progress, or send them as asynchronous jobs and take a webhook per document. Neither path holds a connection open while thousands of PDFs render.
Back in the response for a single document, or straight into your own S3-compatible storage when you configure a delivery destination. The archived copy then lives in the bucket your retention policy already covers.
Issue a signed render URL. The customer fetches the document directly, with an expiry you set, so your application does not proxy the bytes or hand out an API key.
Two credits per PDF. An identical repeat comes from cache for nothing, which matters when a customer downloads the same invoice four times, and failed work is refunded.
No, and they should not be. Your billing system owns the invoice number, the tax treatment and the totals. Renderwolf renders the document your system produced, which is what keeps the PDF and your ledger in agreement.
No. The output is a standard PDF. PDF/A archival profiles and the structured formats such as Factur-X, ZUGFeRD and PEPPOL are not produced, so if a customer or a tax authority requires one, you will need a step that emits it.
Create an account, take a key and post the HTML your billing screen already produces. The first invoice is inside your free credits.
250 free credits each month, with no card required, hard usage caps and refunds on failed work.