Skip to main content
A JSONL file furnishes a whole batch of records at once. There is one file format and two ways to deliver it:
  • The dashboard — upload a file from the SOLO dashboard. No credentials or file-transfer infrastructure beyond your sign-in.
  • SFTP — drop files from systems that already produce them on a schedule.
Both run through the same furnishing pipeline: each record is routed by its _type to the network’s mappings, which match it to a subject and persist it.

File format

A JSONL file is UTF-8 text with one JSON object per line:
furnish_records.jsonl
  • Extension — .jsonl.
  • Blank lines are skipped and don’t count as records.
  • Every line is independent. A line that isn’t valid JSON fails on its own; the rest of the file still ingests.
  • Field names are whatever your network’s mapping reads — the example above is illustrative. Write identifiers such as SSNs and EINs as strings.
For dashboard uploads, the filename must have exactly one dot and a name made of letters, digits, underscores, and hyphens — consumers_aug.jsonl is valid; consumers aug.jsonl (space) and consumers.aug.jsonl (two dots) are rejected — and the file can be at most 10 MB.

Record types

Every record carries a _type field naming what kind of record it is. That value is how the network decides which mappings receive the record:
  • Each feed in the dashboard declares a sample record. The sample’s _type is the record type that feed’s mappings claim.
  • A record is sent to every active mapping in the target network that claims its _type. One record can therefore feed several mappings.
  • A record whose _type no mapping claims is counted as unmatched and skipped. Unmatched records never fail the file: they’re expected when a file carries record kinds this network doesn’t ingest.
  • A mapping’s assignment to a network can be bounded to a date window. A record whose type is claimed but that arrives outside every claiming mapping’s window is reported separately from an unclaimed type, so the two causes are easy to tell apart.
The rest of each record is whatever your mapping reads. The mapping’s source schema, shown on the feed in the dashboard, lists the fields it requires.

Choosing the network

Records are written to exactly one network per file:
  • Dashboard — the upload dialog asks which network to furnish into. It selects the network automatically when you can furnish into only one.
  • SFTP — put the file under network_<network_id>/jsonl_furnish_data/ to name the network. Always use this per-network folder; see Directory layout.
Either way, your organization must hold the furnisher or governor role in that network.

Uploading from the dashboard

The JSONL upload dialog opens from three places:
  • Upload JSONL records in the command palette.
  • Furnish on a product’s detail page.
  • Upload data on an SFTP feed’s detail page.
Pick the file, confirm the network, and submit. The upload is accepted immediately and ingested in the background. The Furnish button in the dashboard’s top bar opens a separate dialog that accepts more than JSONL:
  • Records — CSV, TSV, JSON, or JSONL files, or records pasted directly. The dialog matches them to one of your feeds, or helps you set up a new feed and its mapping. It furnishes up to 1,000 records (5 MB) at a time; for more, use the JSONL upload dialog or SFTP.
  • Documents — PDFs, images (PNG, JPEG, GIF, WebP), Word documents, and text or Markdown files, up to 10 MB each. An AI model provided by Anthropic reads each document for the people or businesses it describes, and you review the extracted records before anything is furnished.

Results

When ingestion finishes, the upload records what happened to every line: Errors are grouped by cause, with sample line numbers, so a thousand records failing the same way show up as one error rather than a thousand. Review them on the dashboard’s Uploads page, or on a feed’s recent deliveries, which also name the unmatched record types.
Re-sending is safe for identities: a record resolves to the existing consumer or business on its natural key (SSN and date of birth for consumers; federal EIN and jurisdiction of formation for businesses), so a re-upload attaches to the same profile instead of creating a duplicate. Verification events in a re-sent record are added again, though — re-send only the records that failed.

Failure modes

The dashboard checks the extension, the filename rules, and the size before sending anything. Rename the file (letters, digits, _, -, one dot, .jsonl) or split it into smaller files.
The file isn’t UTF-8 JSONL — often a JSON array ([{…},{…}]) or a pretty-printed object spread across several lines. Write one compact object per line.
No active mapping in the target network claims their _type. Check the value against the feed’s sample record, confirm the mapping is active rather than a draft, and confirm the file went to the network you expected.
The record doesn’t carry what the mapping reads — usually a missing required field or a value of the wrong type. The grouped error names the field; compare the record with the mapping’s source schema.

In the dashboard

Product furnish — JSONL records ready to upload

Product furnish — JSONL records ready to upload

Product furnish — upload accepted, dialog closed

Product furnish — upload accepted, dialog closed

File uploads list (ingest status)

File uploads list (ingest status)

When to use a different channel

  • One record at a time, in real time — use the product furnish endpoints, e.g. POST /v1/products/kyc_certificate_snapshot/furnish. See the furnishing overview.
  • Recurring drops from systems that produce files natively — use SFTP. Same files, same pipeline, no dashboard session required.

SFTP Getting Started

Deliver JSONL files on a schedule.

Furnishing Policies

How mappings turn records into network data.