Convert CSV to JSON on upload

Partners send what their systems can produce: a vendor exports a comma-separated order file, a carrier emits XML, a legacy ERP spits out a fixed-width EDI batch. Your application wants clean, validated JSON. The usual fix is a conversion microservice that watches a drop folder, reparses every dialect, and falls over on the one row with an unescaped comma. FTPasHTTPS moves that conversion into the upload itself, so your endpoint only ever receives the shape it asked for.

How inline conversion works

1. A client uploads a file via STOR over SFTP, FTPS or FTP.
2. FTPasHTTPS detects the format and applies your transform — for example, parse CSV and emit JSON.
3. If a schema is configured, the parsed records are validated. Invalid files are rejected before anything downstream sees them.
4. The converted output is forwarded to your webhook (HMAC-SHA256 signed) and/or written to S3, GCS, Azure Blob or another SFTP server.
5. Your endpoint's 200 maps to 226 Transfer complete; a validation failure or 5xx maps to 451 Action aborted.

Configuration + example payload

The transform is declared on the server. Here a CSV upload is converted to JSON, validated against a schema, then delivered:

# CSV -> JSON transform with schema validation
{
  "protocol": "sftp",
  "transform": {
    "from": "csv",
    "to": "json",
    "csv": { "delimiter": ",", "header": true },
    "validate": { "schema": "orders.schema.json", "onError": "reject" }
  },
  "forward": [
    { "type": "webhook", "url": "https://api.acme.com/orders",
      "hmac": { "algorithm": "sha256", "secret": "${WEBHOOK_SECRET}" } },
    { "type": "s3", "bucket": "acme-orders-json",
      "keyTemplate": "json/{date}/{filename}.json" }
  ]
}

A vendor uploads plain CSV:

# orders-2026-06-20.csv (what the vendor sends)
order_id,sku,qty,price
A-1001,WIDGET-RED,4,9.99
A-1002,WIDGET-BLUE,1,12.50

Your webhook receives validated JSON — no CSV parsing on your side:

// POST body delivered to https://api.acme.com/orders
[
  { "order_id": "A-1001", "sku": "WIDGET-RED",  "qty": 4, "price": 9.99 },
  { "order_id": "A-1002", "sku": "WIDGET-BLUE", "qty": 1, "price": 12.50 }
]

Inline transform vs. a DIY conversion service

Concern	DIY drop folder + parser service	FTPasHTTPS inline transform
When conversion runs	After a cron/poll picks the file up	During the upload, streaming
Bad-file rejection	Discovered downstream, after accept	Rejected at upload with 451
Schema validation	Hand-rolled per format	Declared once, enforced inline
Formats handled	Whatever you coded	CSV, JSON, XML, EDI-style
PGP / compression	Separate steps to wire up	Part of the same flow
File on disk	Sits in the drop folder	Never touches disk
Retries & audit	You build it	Backoff, dead-letter queue, audit log

When to use it (and the limits)

Inline conversion is the right tool when partners send formats your app does not speak, when you want malformed files bounced at the source instead of poisoning a queue, or when each new vendor currently means another bespoke parser. It is especially handy for order, inventory and EDI feeds where the structure is known and a schema can enforce it. Transformations and schema validation are available from the Professional plan; PGP is an Enterprise feature.

Keep the constraints in mind: transforms operate on structured, record-oriented files — this is format conversion and validation, not arbitrary data enrichment or joins against external systems. Conversion happens per upload, so it is not a batch reprocessor for files already in storage. And very large files are bounded by your plan's transfer and size caps.

Why validate at the edge instead of downstream

The biggest win of converting on upload is not the format change — it is rejecting bad data before it becomes your problem. When validation runs inside a downstream worker, a malformed file has already been accepted: it sits in a queue, triggers a partial run, or worse, gets half-processed before the bad row surfaces. Cleaning that up means reconciliation, dead-letter triage, and an awkward email to the partner days later.

Validate at the edge and the failure happens where it is cheapest to fix. A file that violates the schema never produces a webhook call or an object in your bucket; the uploading client gets 451 Action aborted on the spot, so the partner's own system flags the failed transfer immediately and can resend a corrected file. Your application, meanwhile, is guaranteed that anything it receives already matches the contract — right field names, right types, right shape — which means no defensive parsing, no per-vendor special cases, and a far smaller surface for injection or malformed-input bugs. The audit log captures every rejection alongside every accepted transfer, so you always have evidence of what was refused and why.

Frequently asked questions