Skip to main content

Reuse .doqlo Project Files Across PDFs

Use this page when you want to understand why Doqlo allows one .doqlo setup to keep working across changed or related PDFs.

This same policy applies in both places where you use .doqlo:

  • in the Bulk Fill web editor, where you open a saved .doqlo project file
  • in the Public API, where you submit a .doqlo package for execution

The name changes slightly by context, but the product policy is the same: Doqlo treats .doqlo as reusable configuration, not as a rigid lock to one exact PDF fingerprint.

Why Doqlo Works This Way​

Real business documents often change a little over time even when the workflow is still the same.

Common examples:

  • the date or revision label changes
  • a disclaimer is updated
  • one page is added
  • one page is removed
  • a few pages are amended while the main layout still matches
  • PDF metadata changes even though the visible document is still compatible

If .doqlo were locked to the exact PDF it was created from, teams would have to rebuild field placement and CSV mapping every time one of those routine changes happened.

Doqlo is designed to avoid that unnecessary rework.

What Doqlo Allows​

Doqlo allows a valid .doqlo setup to be reused across the same PDF, a slightly changed PDF, or a related PDF when the layout still makes practical sense.

That means:

  • a changed PDF does not automatically invalidate a valid .doqlo
  • a PDF mismatch by itself is not treated as proof that your setup is wrong
  • Doqlo can still let you continue when the document is different but still usable

This is intentional product behavior, not a loophole or fallback.

What Still Stays Strict​

Flexibility does not relax file validity or package integrity rules.

Doqlo still rejects .doqlo files that are:

  • tampered with
  • malformed
  • unsupported
  • not produced by Doqlo

Doqlo also does not automatically redesign your layout for you. If the document changed in a way that affects field placement, you still need to review the result.

What Happens When The PDF Is Different​

When you open or execute a .doqlo against a different PDF, Doqlo treats the PDF difference as diagnostic context first.

In practice, that means:

  • if the changed PDF is still compatible enough, Doqlo can continue
  • if some placements still make sense, Doqlo keeps using them
  • if a placement targets something that no longer exists safely, Doqlo skips that placement instead of failing the whole accepted workflow

Examples:

  • If the new PDF has the same practical layout but a different fingerprint, Doqlo can still continue and tell you the PDF is different.
  • If one page was removed and overlays were placed on that missing page, those overlays are skipped instead of blocking the whole import or accepted API job.
  • If the saved current page from the editor no longer exists, Doqlo adjusts the restored page instead of failing the import.
  • If the API executes against a changed but still compatible PDF, the job can still complete and report the PDF difference in manifest.json.
  • If only some overlays can be applied safely, produced rows can still come out as partial instead of turning the whole job into a hard failure.

What This Means In The Editor And API​

In the Bulk Fill editor:

  • you can open a .doqlo project file on a different PDF
  • Doqlo can warn you that the PDF changed without blocking you immediately
  • you should review imported fields before trusting the next batch export

In the Public API:

  • you can submit a .doqlo package with a different but still compatible PDF
  • accepted jobs run best-effort against that submitted PDF
  • top-level PDF diagnostics and row-level partial results are reported through manifest.json

The same design principle is behind both experiences: keep useful work moving when the document changed slightly, while staying explicit about what happened.

What Doqlo Does Not Promise​

Doqlo does not promise that a changed PDF will always produce identical output.

It does not:

  • auto-reposition fields on a changed layout
  • guarantee that every prior placement still fits
  • hide skipped overlays or partial results

If the layout changed in a meaningful way, review is still required.

Best Practice Before A Batch Export​

When you reuse a .doqlo on a changed or related PDF:

  1. Open the project or run a small API test first.
  2. Review the affected fields.
  3. Preview representative rows, especially long values and edge cases.
  4. For API runs, inspect manifest.json when the submitted PDF differs from the original authoring context.

That gives you the flexibility to avoid rebuilding the whole setup while still keeping output quality under control.