Fill a Calculated PDF From JSON and Let the Server Compute Totals

A calculated PDF API is most reliable when the external system sends the source facts and the template computes the derived fields. If every caller sends its own total, the PDF template no longer owns the calculation rule. Different services can drift, round differently, or accidentally send stale values.

DullyPDF keeps the template in charge. The API schema should expose number inputs such as quantity, rate, tax, discount, or deposit. Calculated outputs such as subtotal, total, and balance due are computed when the backend materializes the PDF.

Search & Fill is an operator workflow: a user chooses a row in the browser and reviews the output. API Fill is a server workflow: another system sends JSON to a published endpoint and receives a PDF. Calculation fields work in both flows, but the trust boundary is different.

That is why a published calculated template needs a stable schema and endpoint contract. Once the endpoint is live, caller expectations should not change accidentally because someone renamed a field or changed a formula without republishing intentionally.

A caller should send only the source fields the template expects. For an invoice, that might be customer_name, quantity_1, unit_price_1, tax_rate, discount, and amount_paid. The response PDF can include line_total_1, subtotal, tax_amount, grand_total, and balance_due even though the caller did not send those derived fields.

This separation makes the endpoint easier to validate. Missing source inputs are request errors. Calculated output inputs are either rejected in strict mode or ignored in non-strict mode because the template formula owns those values.

Calculated API Fill is a good fit when another system already owns the source record: billing software, a CRM, an internal admin portal, a loan intake system, or an order management tool. The system can call one endpoint and let the template handle the PDF-specific math.

It is not a replacement for a general document-generation engine with dynamic page layout. It is strongest when the PDF layout is fixed and the repeated job is filling known fields and computing known derived values.

A useful api fill calculated pdf test starts with one document your team already recognizes, not a perfect demo PDF. Open the existing file, review detection, rename ambiguous fields, confirm checkbox and radio behavior, and save the template only after the field list matches the way the document is used in practice.

Then fill one representative record end to end. Include long names, blank optional values, dates, yes/no choices, and any calculated or scannable fields the page depends on. That single controlled run exposes most template issues before they become repeated output problems.

Search & Fill is the right first path when an operator should pick a record and inspect the result before export. It works with row data from CSV, XLSX, JSON, or stored respondent records. SQL and TXT files should be treated as schema-only mapping inputs; database-backed production workflows should query the database elsewhere and send JSON through API Fill.

Output mode matters too. Editable PDFs are useful when someone will continue working in live fields. Flat PDFs are safer when the completed record goes to customers, employees, agencies, signers, or archive systems because the visible values are baked into the page instead of depending on the recipient PDF viewer.

The api fill calculated pdf workflow is ready to reuse when a teammate can clear the document, rerun the same source record, and produce the same visible PDF without remembering hidden cleanup steps. If the result depends on one person knowing which field to fix manually, the template still needs review before it belongs in a repeat workflow.

• The saved template uses stable field names and reviewed field types.
• Source headers or API keys match the template schema without ambiguous duplicates.
• Checkbox, radio, calculated, image, barcode, and signature fields have been tested if the workflow uses them.
• At least one flat output and one editable output have been opened in the PDF viewers recipients are likely to use.