DullyPDF Usage Docs

Implementation-level guide for the full DullyPDF workflow, including concrete limits, matching rules, radio groups, API Fill, and signing behavior.

How to use this docs page

This page is meant to answer one operational stage of the DullyPDF workflow well enough that you can run a controlled test without guessing. Read the sections below, validate the behavior against one representative document, and only then move to the next linked page.

That order matters because most setup failures come from mixing detection, mapping, fill validation, and sharing into one unstructured pass. A narrower review loop keeps troubleshooting faster and makes the template easier to trust once you save it for reuse.

Full product tour

7-minute DullyPDF feature walkthrough

This broader video covers the main product surface: PDF-to-template setup, Search & Fill, saved templates, Fill By Link, API Fill, and signing handoff.

7 minutesWatch on YouTube

Use the full tour when you want product context across the public workflow pages before drilling into one feature-specific doc or landing page.

Official DullyPDF profiles

These links help operators move between the public docs, product demos, company presence, and open-source implementation without falling back to the homepage.

Company updates, positioning, and product-facing posts.

GitHub

Open-source repository, implementation details, and change history.

YouTube

Product demos, walkthroughs, and feature explainers.

Short product updates, launches, and distribution posts.

Pipeline overview

DullyPDF runs a fixed sequence: PDF upload -> CommonForms detection -> optional OpenAI Rename and/or Map -> editor cleanup -> saved template -> Search & Fill or Fill By Link respondent selection -> download/save.

Route-level behavior: `/detect-fields` creates the detection session, `/api/renames/ai` performs rename, `/api/rename-remap/ai` performs the combined Rename + Map action, `/api/schema-mappings/ai` performs standalone remap, and Search & Fill runs over your local rows or stored Fill By Link respondent records.

Before you start

PDF upload limit is 50MB (`UploadComponent` validation).
Desktop is required for full editor usage. Mobile is walkthrough-only.
Search & Fill record rows can come from CSV, XLSX, JSON, or stored Fill By Link respondents. SQL and TXT are schema-only.
Fill By Link can be published from the active saved form or from an open group. Owners now use a larger builder dialog with global settings, searchable questions, and live preview before publishing.
OpenAI actions require sign-in and credits. Rename and Map pricing is bucketed by page count (default 5 pages per bucket).
Rename/Map credits formula: total = baseCost x ceil(pageCount / bucketSize). Base costs: Rename=1, Remap=1, Rename+Map=2.
Fill from Images and Documents credits: each image costs 1 credit; each PDF document costs 1 credit per 5 pages.
Billing runs through Stripe from Profile: Pro Monthly, Pro Yearly, and a Pro-only 500-credit refill pack.
Public plan explainers live at /free-features and /premium-features.

Choose the right docs page

Use Detection for confidence tiers, geometry shape, and coordinate behavior.
Use Rename + Mapping for OpenAI payload boundaries and checkbox/radio rule precedence.
Use Editor Workflow for drag/resize constraints and edit-history behavior.
Use Search & Fill for row caps, query modes, Fill By Link respondent use, and field resolution heuristics.
Use Fill By Link for published link creation, respondent expectations, and response review.
Use Signature Workflow for email-based signing, web-form-to-sign handoff, immutable record freeze, and owner artifact retrieval.
Use API Fill for template-scoped JSON-to-PDF endpoints, key rotation, hosted schema downloads, and server-side fill guardrails.
Use Create Group for packet workflows, group Search & Fill, and batch Rename + Map behavior.
Use Troubleshooting for exact validation/error messages and fast diagnosis steps.

Public routes versus docs

The workflow and industry landing pages are meant to explain why a route exists and what kind of problem it solves. The usage docs are where the implementation details live. If a search-intent page answers the strategic question and you are ready to build, come back here for the exact runtime behavior.

That split is deliberate. It keeps commercial pages focused on the document problem and keeps the docs focused on operator behavior, guardrails, limits, and validation steps. The safest path is usually: choose the right route first, then use the matching docs page to validate one representative workflow.

Three fastest starting paths

Template setup: start with Getting Started when you need one recurring PDF to reach its first safe fill quickly.
Row-based filling: start with Search & Fill when the record already exists in CSV, SQL, XLSX, JSON, or a stored respondent submission.
Respondent collection: start with Fill By Link when the row does not exist yet and someone must submit it first.

First validation loop

Choose one recurring document, not every possible packet variation.
Run detection and review low-confidence items first.
Normalize names and mappings before you worry about volume.
Fill one representative record and inspect the output PDF carefully.
Only after that should you publish a Fill By Link, group the template, or expose an API endpoint.

Hard numbers used by the app

Confidence tiers: high >= 0.60, medium >= 0.30, low < 0.30.
Search results are capped at 25 rows per query.
CSV/XLSX/JSON parsing caps rows at 5000 records per import.
Schema inference samples up to 200 rows when inferring field types.
Field edit history depth is 10 snapshots (undo/redo).
Minimum overlay geometry is type-based: text/date/checkbox = 12 points, signature = 16 points.