Output formats and limits
The numbers you need before you design around Papers: which formats it produces, what a request may contain, and where it says no.
The five output formats
outputFormat takes pdf, docx, html, plaintext or markdown, in any case. txt and md
are accepted as short forms of the last two.
pdf is the one to use for anything a person receives or signs. It is rendered by a real browser
engine, so the page layout, the fonts and the images are what the editor showed you.
docx produces a Word file for a document somebody has to edit afterwards. It is a genuine
conversion rather than a PDF in a wrapper, so complicated layout comes out approximately.
html returns the document as markup, which is useful when you are embedding it in a page or an
email, and it skips the PDF step.
plaintext is the text with the formatting stripped, and links show their address. Use it for
indexing, an SMS or a plain-text fallback, not for anything a customer reads as a document.
markdown keeps the structure as Markdown: headings, lists, bold and italic, and tables. Formatting
Markdown has no way to write, such as underline or highlight, keeps only its text. It suits a system
or an AI tool that reads Markdown.
Anything else is a 400 listing the five.
The format is per request, not per template
Nothing on a template fixes its output format. The same published version renders as a PDF for your customer and as text for your search index, from two requests that differ by one field.
Input formats
inputFormat is json or xml, and json is the default. Leave it alone unless you genuinely
have XML.
Password-protect a PDF
password encrypts the generated PDF so it cannot be opened without it. Up to 128 characters.
It is PDF only. Send a password with any other format and the request is refused with a 400
rather than quietly ignored. In a batch, a password on an item overrides the batch's own.
The password is never stored and never logged, which also means Papers cannot tell you what it was. Keep your own record before you send documents nobody can open.
Batch limits
A batch takes between 1 and 500 items. Over 500 is a 400, so split the work yourself.
One item per document: a batch of 500 payslips is 500 items over one template. The download is a
ZIP of the ones that succeeded, and a batch can come back completed_with_errors with the failures
listed per item.
Rate limits
Two limits are enforced, and both are per minute.
The signing wizard's preview render allows 60 requests a minute per user. The signer portal allows
100 requests a minute per signing link. Both answer 429 when exceeded.
Generation has no 429 limit of its own today. Do not design a load test around that: queue your
work and keep a sensible ceiling on concurrency, because the sane number is the one your own system
can handle downloading.
Papers counts every API call, generation included, as usage on your plan. Plan & Usage at the
bottom of Settings shows your plan's limits, and View usage details shows what you have used.
Requests also need the company's subscription to be in good standing. If it is not, they come back
402 with a subscribeUrl.
Uploads
A PDF uploaded for signature can be up to 25 MB.
A font face is up to 5 MB per file, in .woff2, .woff, .ttf or .otf. A signature image
uploaded by a signer is a PNG or JPEG up to 2 MB, and no bigger than 2000 by 500 pixels.
A Word document imported as a new template through POST /v1/templates/import is a .docx up to
25 MB. An older .doc file has to be saved as .docx in Word first.
What the API does not do
There is no endpoint for creating a company, managing users, or anything a signer does in the portal. Those are the web app and the signing links.
The endpoint list, with every field, is at papers.ebizi.co.za/docs. Besides generation, it covers templates, fragments, fonts, assets, environments, signing requests and webhooks.