Loading

Supported File Formats

Extraction reads five formats. All of them are structured: the value must be locatable by a path or a column, not recognised from an image.

Where to find it

Architect Panel → Data:

  • Data Extraction — where the format is chosen per definition

CSV

Comma-separated values, mapped by column. The most common format for scheduled feeds, and the easiest for a sender to produce.

One practical constraint: CSV must be supplied as a file, not as raw text in a payload. A sender posting CSV content in the body of an API call needs to send it as a file instead.

JSON

Mapped by path, descending through the structure with a separator — order/lines/reference. The natural choice for API integrations, and the format that handles nesting and optional values most gracefully.

Spreadsheets

XLS and XLSX, mapped by column like CSV. Useful when the sender is a person rather than a system, because it is what they already have.

Be aware that spreadsheets carry formatting, and formatting is where surprises live — a reference column that Excel has interpreted as a number will have lost its leading zeros before the file ever reaches you. Ask senders to format such columns as text.

XML

Mapped by path, like JSON. Common in established B2B integrations and in anything with a formal schema behind it.

DAT

Delimited, line-oriented files, with support for multiple record types in one file — the shape where a header line, several detail lines and a trailer line each have a different layout.

This is the format that appears when integrating with older systems, and the multi-record-type support is the reason it is worth having: those files cannot be treated as a simple table.

Choosing

You usually do not — the sender does. Where you can influence it, prefer JSON or XML for anything with nesting or optional fields, and CSV for flat tabular data. Both are unambiguous in a way spreadsheets are not.

Agree the format in writing

Not just the file type, but the field list, whether a header row is present, the date format, the character encoding, and what an empty value looks like. Every one of those has caused an integration to fail on its first real file, and all of them are cheap to agree in advance.

Encoding

Ask for UTF-8. A file in another encoding will usually load and then present as corrupted characters in names and addresses, which is the kind of problem that gets noticed by a customer rather than by a monitor.

Worked example

A local authority receives three feeds: a nightly CSV of housing benefit changes, a partner posting referrals as JSON, and a legacy finance system producing a DAT file with header, detail and trailer records. One extraction definition handles each, and the DAT definition maps the three record types separately.

Recommendations

  • Prefer JSON or XML where the data has structure.
  • Send CSV as a file, never as raw text in a payload.
  • Agree encoding, dates and empty values in writing.
  • Ask spreadsheet senders to format reference columns as text.