High-level concepts

The SOLO Network is a shared data network. Participants furnish verified data about consumers and businesses, and query that data back — under clear rules about who can read what, and why. Six concepts power everything you do with the API. Once you understand them and the order they come into play, every endpoint in the reference reads naturally.

​

The building blocks

​

Network

A network is the trust boundary everything else lives inside. It groups a set of participating institutions, defines which products are available to them, and contains the data they furnish. Nothing crosses a network boundary: a record furnished into one network is invisible to every other, and every API call that touches data — a consent lookup, an entity search, a product query — is scoped by a network_id. Within a network, each participant holds one or more roles — governor, furnisher, querier — that determine which operations it may perform, and governance rules determine how the network itself is administered and changed.

​

Entity

An entity is a subject of the network: a consumer (a person) or a business. Every furnish writes data about an entity, and every query reads data about one. Entities have a core identity — name, email, SSN or EIN, date of birth — that the network uses to recognize when two participants are talking about the same subject, so that data furnished by one bank can be consolidated with data furnished by another. You can look up existing entities with GET /v1/entities/consumer/search and GET /v1/entities/business/search, both scoped by a required network_id.

​

Consent

Consent is the subject’s permission, captured as a first-class record. Before you query data about a consumer or business, you record that they agreed — POST /v1/consent/consumer or POST /v1/consent/business — and receive a consent_id that you pass with every subsequent query. A consent record carries a scope, an optional expiry, and the set of consented fields; scope, expiry, and consented fields can be updated later, but the identity fields are immutable, because the record is an audit artifact of who consented and when. The API refuses to create a consumer consent unless you affirm that consent was actually gathered from the consumer first.

​

Product

A product is the unit of data you furnish or query — a standardized package rather than a raw table. The network currently offers KYC and KYB certificates (consolidated identity-verification outcomes for consumers and businesses respectively) and screening lists (a bank-specific bad-actor list and a cross-bank financial-crimes watch list). Products expose query and, where applicable, furnish operations under /v1/products/{product}/…. A non-billable soft check, POST /v1/products/check, reports per-furnisher field coverage for a product before you commit to a billable query.

​

Policy

A policy is a per-network, per-product rulebook authored by the network governor. A querying policy defines what a product is allowed to read — which models and which fields appear in query results for that network. A furnishing policy defines what a product accepts on write and how submitted data is validated and transformed. Policies are created as shells (POST /v1/networks/policies/querying, POST /v1/networks/policies/furnishing) and then configured field by field via their PUT /v1/networks/policies/…/{policy_id}/configuration endpoints. A query names the policy it runs under, so the same product can behave differently in different networks.

​

Entitlement

Entitlement answers the last question: of the fields the policy exposes, which ones can you see? Entitlement is earned through participation — by previously furnishing data about an entity or querying it — and is evaluated per field at query time. Two participants issuing the identical query against the same entity can receive different results, each limited to the data their own history entitles them to. This is the mechanism that makes a shared network safe: contributing participants are never exposing data to passive observers.

​

The data flow

The building blocks come into play in a fixed order. Here is the lifecycle of a participant from joining a network to reading its first query result:

1. Join a network. Your organization is added by the network governor and assigned roles. From this point your token resolves to an account with capabilities inside that network. See Join a network.
2. Create consent. Record the subject’s permission and hold on to the returned consent_id. Without it, product queries fail.
3. Furnish. Contribute data through a product’s furnish endpoint — or in bulk via file upload or SFTP. The network’s furnishing policy validates what you send.
4. Query. Ask a product for consolidated data, citing your consent_id and the network policy to run under. The result is assembled from every furnisher’s contributions — filtered through the policy and your entitlement. If the available data cannot satisfy the policy’s requirements, you receive an empty 204 No Content rather than a partial answer.

​

How the pieces enforce privacy

The model is easiest to remember as three independent gates, each answering a different question. All three must open before a field reaches your response. Roles grant capability. A participant without the querier role cannot query anything, no matter how much consent it holds. Roles are assigned by the network governor and checked on every request. Consent grants permission. A querier with full capability still cannot read a specific consumer’s data without that consumer’s consent record — scoped, optionally time-limited, and auditable after the fact. Entitlement grants visibility. Even with capability and permission, you see only the fields your participation has earned, and never more than the network’s querying policy exposes to anyone. The policy is the ceiling; entitlement is your position under it. Because the gates are independent, no single actor can bypass the system: the governor controls policies but not consent, the subject controls consent but not entitlement, and your own history determines entitlement but not capability.

​

Where to go next

If you learn best by doing, the Quickstart chains the full flow — consent, furnish, query — into a few curl commands. If you are about to write integration code, read Authentication to set up your bearer token and Errors to handle failures correctly — in particular the distinction between a 204 empty result, a 400 domain rejection, and a 422 malformed request, all of which you will encounter while integrating. For depth on any single building block, follow its link above into the concepts section. Two reading paths are worth calling out: if your organization primarily contributes data, continue from Furnishing into file upload and the SFTP guide for bulk ingestion; if it primarily consumes data, continue from Querying into the individual product pages — KYC certificate, KYB certificate, and screening lists.