From spreadsheet CSV to API JSON: why every value arrives as a string

The import that rejected every row — an API expecting numbers and booleans, and a JSON body full of "42" and "TRUE"

The outline describes an API import produced by CSV-to-JSON, but Syntax converters cannot perform that action. CSV is marked unreadable, no conversion pair starts with CSV, and the interface never offers it as a source. An attempted request returns an unsupported-conversion error rather than guessed JSON.

This correction is the article’s central fact, not an omission to hide. A product manager can still prepare a spreadsheet export, but parsing and typing need a CSV workflow that exposes the decisions. Writing fictional steps for this panel would send readers to controls that do not exist.

The requested CSV-to-JSON import cannot run in this panel

CSV fields are text sequences separated and quoted under a dialect. The file does not carry spreadsheet number formats, Boolean types or nested objects. It may not even state its delimiter or whether the first record is a header. Those uncertainties arise before any JSON type decision.

A leading-zero postcode, long identifier and date-like value demonstrate why automatic coercion is risky. Yet “everything is a string” also requires a header and dialect choice. ToolAcre refuses the complete read operation rather than implementing only the easy half and presenting it as reliable.

CSV carries text fields but the reader must still choose a dialect and header policy

Type inference trades convenience for silent corruption. `0042` can be a code, `9007199254740993` exceeds exact JavaScript integer precision, and `N/A` may be a literal category rather than missing data. Locale-specific dates and decimals introduce more interpretations.

The correct types come from the receiving API schema and import policy, not from the surface appearance of cells. A careful workflow first parses rows under explicit CSV rules, then converts selected fields according to that contract and reports failures row by row.

Preparing the spreadsheet — consistent columns, explicit true/false, no thousands separators and empty cells for genuinely missing values

Prepare a consistent file: one header policy, one delimiter, valid quoting and a documented encoding. Decide how empty cells differ from empty strings and null. Use explicit true and false spelling only if the importer maps them that way; avoid thousands separators unless the chosen dialect and type parser expect them.

These are recommendations for an import workflow, not features of Syntax converters. The repository points users to a CSV tool because it can ask the questions this one intentionally avoids.

Preparing CSV belongs in a tool that asks about delimiter, quoting, headers and types

The code-accurate worked result is a refusal. Calling `convert` with CSV as source and JSON as target produces `UNSUPPORTED_CONVERSION`; the hint explains that CSV reading needs delimiter, quoting and type decisions. There is no partially converted body to edit afterward.

Use CSV Cleaner to inspect and repair the file, then an importer whose settings match the API schema. If the data is already represented as JSON records, the supported reverse direction can write CSV and exposes flattening, null ambiguity and formula escaping.

Worked boundary: the unsupported request and the supported alternative workflow

Decimal commas often accompany semicolon-separated records, while date notation varies by exporter locale. A parser choosing comma blindly can split numeric values; a type guess can reinterpret day and month. Character encoding and BOM handling add another boundary before field semantics.

Because this route does not read CSV, it makes no claims about handling those cases. The JSON-to-CSV writer can choose comma, semicolon or tab and optionally add a UTF-8 BOM, but output options are not evidence of an input parser.

What this does not cover — nested structures the API might require, which CSV cannot express and must be assembled after conversion

CSV cannot directly represent the nested object an API may require. Dot-separated headers can be a convention, but they do not automatically create objects unless the importer defines that rule. Arrays and repeated nested records need an explicit assembly stage.

A generic syntax converter cannot infer business structure from a flat table. Define the target JSON schema, map columns deliberately and validate before sending. That is application integration rather than syntax conversion.

Takeaway: types are your decision, not the converter's — and how the Syntax converters panel shows you the JSON before you send it

Types are decisions backed by the receiving contract. ToolAcre’s refusal keeps those decisions visible instead of manufacturing plausible but risky JSON. It is better to stop than to destroy leading zeroes or round an identifier silently.

Use Syntax converters for its nine listed directions, including JSON-to-CSV. For CSV-to-JSON, choose a tool that asks about dialect, header and types. The missing route is a deliberate safety boundary, not an unfinished button.

Before importing a real spreadsheet, write down the decisions the absent button would otherwise hide: encoding, delimiter, quote rule, header row, duplicate-header policy, empty-cell meaning and a type rule for every destination field. A CSV reader configured from that list can produce accountable JSON. A generic converter that never asks those questions may look faster, but any saved time is borrowed from debugging identifiers, dates and missing values after the API rejects or misreads them.