Skip to main content
Furnishing is how a participant contributes verified work into a network. It’s the write half of the network: a verification your institution already performed becomes a trust asset that backs certificates for the participants entitled to read it.

​
Contributing is asset creation, not data donation

The natural fear of contributing is “I’m giving away proprietary customer intelligence and losing control.” A SOLO network is designed so that isn’t what happens. When you furnish a verification, it becomes an attributed, governed asset:
  • You keep attribution. Every certificate sub-product your data backs carries your furnishing_entity_id. The verification travels with your name on it — see Provenance.
  • You keep governance. Contributed data is gated by the subject’s consent, the network’s querying policy, and each reader’s entitlement. Sharing a network with you does not let another member read what you furnished.
  • You keep read access. Records you furnish are always readable to you, so they back your own certificates and queries.

​
The furnishing channels

There are three ways to get records into a network. The differences are in transport, batch size, and how much automation you want to build. When to choose each:
  • REST furnish when furnishing is an event in your system — a consumer finishes onboarding, you furnish their record in the same workflow. Lowest latency, immediate feedback, no file handling.
  • Dashboard upload when you have a file in hand — a one-off historical load or a periodic batch you’d rather not automate.
  • SFTP when your data already leaves your systems as files on a schedule. Most core-banking and data-warehouse stacks can target an SFTP endpoint with no custom code.
REST furnish writes records directly in the product’s shape; file records are turned into network data by the network’s furnishing policies. Every channel matches subjects on the same natural keys and attributes each record to your organization.

​
How a furnish works

A furnish brings together a network, your records, and the consumer (or business) they describe:

​
Anatomy of a REST furnish

You call the product’s furnish endpoint with the network and one or more records. For a KYC certificate:
A successful furnish returns:
Request fields:
  • network_id — the network you’re furnishing into. You must hold the furnisher or governor role there; otherwise the request fails with 403 PERMISSION_DENIED.
  • records — one or more consumer records. Each carries first_name, last_name, date_of_birth, and social_security_number (all required strings), plus optional lists of verification records: document_capture_events, biometric_capture_events, liveness_check_events, identity_document_identities, identity_corroboration_events, and address_identities (each address can carry its own address_capture_events). SSN and date of birth together are the key that matches the record to a consumer entity.
Response fields:
  • profile_ids — the consumer or business profile each record resolved to, in the order you sent them.
  • counts — how many rows were written per record type.
The response carries no furnish or submission id to look the request up later; keep profile_ids if you need to refer back. POST /v1/products/kyb_certificate_snapshot/furnish takes the same envelope for business records. Each business record requires federal_ein and business_jurisdiction_of_formation — together the business match key — and can carry business_legal_name, business_dba_name, business_email, and lists of business_identity_verification_events, business_ownership_control_verification_events, and business_risk_compliance_events.
A REST furnish processes its records in order as one unit. If any record fails, the request returns an error and none of its records are saved. Fix the failing record and resend the whole request.

​
How file records reach a mapping

You never name a mapping in a file. Each record’s _type does it: the network’s active furnishing policies (mappings) each claim a record type, and every record goes to each mapping that claims its type. Records no mapping claims are counted as unmatched — skipped without being treated as errors. As a furnisher you state facts (network, record type, record); the network’s mappings decide rules. See record types for the details.

​
What happens after ingest

Once a record is accepted, the furnishing pipeline takes over:
  1. Validation. REST records are checked against the product’s record schema; file records against the mapping that claimed them. In a file, each record is processed independently — one bad record doesn’t fail its neighbors. Over REST, a failing record fails the request.
  2. Entity matching. The record’s natural key (SSN and date of birth for consumers; federal EIN and jurisdiction of formation for businesses) is matched to an existing entity, or a new profile is created. A matched profile keeps its existing identity fields.
  3. Records become network data. The furnished verification events are written against that subject, stamped with the network and attributed to your organization.
  4. Certificates. For certificate products, the furnished events become the evidence behind the KYC/KYB certificates built from them, each sub-product carrying your furnishing_entity_id.
  5. Entitlement is recorded. SOLO records which records the furnish wrote or matched for the subject, attributed to your organization — see Entitlement.

​
Data quality expectations

The network is only as good as what’s furnished into it. A few expectations hold across every channel:
  • Identifiers must be real and complete. SSNs, EINs, and dates of birth are matching keys. A typo doesn’t just corrupt one record — it creates a phantom profile or attaches data to the wrong one.
  • Treat identifiers as text. SSNs and tax identifiers are strings, not numbers. Exporting them as JSON numbers silently drops leading zeros.
  • Furnish what the certificate needs. Certificates are built from specific verification events. Records that don’t carry them won’t produce certificates, even if they ingest cleanly.
  • Re-sending is safe for identities, not for events. A record with the same natural key matches the existing profile rather than creating a duplicate — but the verification events it carries are added again as new events. Re-send only records whose events weren’t saved, and don’t “fix” a bad record by changing its identifiers.

​
Mapping dry-run tools

Mappings are saved and activated in the dashboard. Four REST endpoints let you check a mapping document from your own tooling first. They are dry-run only: none of them reads network data or saves anything.
AI-assisted endpoints. suggest and propose use an AI model provided by Anthropic. By default the model sees only the structure of your data — field names and types — never the values. Values are sent to the model only when you opt in: "mode": "structure_with_sample" on suggest, or "share_sample_with_model": true on propose. propose always evaluates the sample on SOLO’s servers to show previews, whether or not it is shared with the model.

​
Furnishing vs. querying

See Querying for the read half.

​
Troubleshooting

Your organization must hold the furnisher or governor role in the target network. See network roles. Check that network_id is the network where you were granted the role — roles don’t carry across networks.
Nothing from that request was saved. Fix the record the error names and resend the whole request.
Most often the records were unmatched: no active mapping in the target network claims their _type. Unmatched records are skipped deliberately, not errored. The upload’s results name the unmatched types — compare them with the record types your network’s feeds declare.
Common causes: missing required fields (all four consumer identity fields are required over REST), malformed dates (use ISO 8601, e.g. 1990-01-15), or empty identifier strings.
Entity matching keys on SSN and date of birth for consumers, and federal EIN and jurisdiction of formation for businesses. If you see duplicates, the identifiers differed between submissions — check for formatting drift such as dropped leading zeros, embedded whitespace, or a different date format.

​
In the dashboard

Feeds — the SFTP drops records arrive on

Feeds — the SFTP drops records arrive on

Product furnish — JSONL upload dialog

Product furnish — JSONL upload dialog

Furnish events history list

Furnish events history list

Furnish event detail — overview tab

Furnish event detail — overview tab

JSONL Files

Furnish whole files of records from the dashboard.

SFTP Ingestion

Recurring JSONL drops, no HTTP client required.

Furnishing Policies

The rules the network applies to what you contribute.

Furnish an entity

A hands-on walkthrough of your first furnish.