Define a fillable PDF template containing a PDF and an XSLT mapping.
Overview
Define a fillable PDF template containing a PDF and an XSLT mapping. Document formats have different failure modes. Confirm whether the workflow transforms data, fills an existing form, packages OpenXML, or only converts a file.
Key points
- Embed the source PDF as base64 in the file element.
- Place mapping XSLT inside the mapping element.
- The mapping transform must return valid JSON.
- Map XML data to actual PDF field names.
- Validate that the PDF contains the expected AcroForm fields.
Example
<template>
<file>BASE64_PDF_CONTENT</file>
<mapping>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:text>{"ClientName":"</xsl:text>
<xsl:value-of select="/data/Client/displayName"/>
<xsl:text>"}</xsl:text>
</xsl:template>
</xsl:stylesheet>
</mapping>
</template>
Replace bracketed values with values issued for the target environment. Never place production tokens, API keys, or client data in screenshots or public examples.
Recommended procedure
- Choose the exact PDF or DOCX workflow.
- Validate the source template or file.
- Submit representative data with the expected response mode.
- Open the resulting file and verify layout, fonts, fields, and metadata.
Troubleshooting
The PDF is blank or malformed
Validate the transform output or field mapping before blaming the conversion engine.
Fonts or pagination differ
Install required fonts and test with the same conversion engine used in production.
Conversion fails for one file
Open and resave the source DOCX, remove unsupported content, and compare it with a known-good file.
Related documentation
Documentation source: feradelinc/feradel.render.api, reviewed against repository revision b2c3a710. Verify behavior against the deployed release before publishing exact routes, limits, or version requirements.