Feeding documents from SQL, REST and CSV
7 January 2026 · 7 min read · Nextarp B.V.
Documents are only as good as the data behind them. A flexible generation platform should meet your data where it lives rather than forcing one integration style. Here are the common paths and when to use each.
JSON payloads
The most direct route: your application already has the data, so post it as JSON with the generation request. Best for on-demand, user-triggered documents where the app is the source of truth.
CSV upload
For bulk runs from a spreadsheet or export, a CSV with a header row maps neatly to a repeating generation. Support a configurable delimiter and explicit date formats so regional files parse correctly.
SQL connectors
When the data lives in a database, a read-only query is the cleanest source - no export step, always current. Keep the connection least-privileged and read-only, and parameterise queries.
REST and OData
For data behind an API, a REST/OData connector pulls records on demand. Handle pagination, authentication and rate limits, and cache where the data tolerates it.
Mapping the data
- Map source fields to the template's data model explicitly, so a source change does not silently break output.
- Validate required fields before generation, not after.
- Use an AI mapping assistant to suggest field matches for large or unfamiliar schemas.
The goal is the same regardless of source: clean, validated data arriving in the shape your template expects.
Related articles
- Integrating document generation over a REST API · Developers
- Generating statements at volume: batch and async jobs · Developers
- eIDAS explained: AdES, QES and QSeal for documents · Compliance