Authentication
Every endpoint under/v1 requires a bearer credential. Only the monitoring
endpoints GET /health and GET /version are unauthenticated, and they return
no customer data.
Credentials are issued through WorkOS, SOLO’s identity provider:
- Organization API keys are the credential for server-to-server use. An authorized user creates and revokes them in the SOLO dashboard under Settings → API keys. The API validates each key with WorkOS and accepts only keys owned by an organization. A key acts as its organization — it carries the organization’s network memberships and roles, with no narrower scopes. Successful validations are cached briefly (by default up to 60 seconds), so a revoked key can keep working for that long.
- Dashboard session tokens are issued when a user signs in to the dashboard. The API verifies their signature against WorkOS’s published signing keys and enforces their expiry.
401 with a short detail message; see
Authentication.
Transport
The API (api.solo.one, api.sandbox.solo.one) and the dashboard
(app.solo.one, app.sandbox.solo.one) are served over HTTPS.
Separate environments
Sandbox and production are separate deployments with separate data. Sandbox has its own database. API keys are created in each environment’s dashboard and should only be used against that environment’s API. Use sandbox, with test data, for integration work.How access to data is scoped
- Membership. Your organization is added to networks in the dashboard;
there is no API endpoint for joining one. Every call that touches data names
the network (
network_id) or networks (network_ids) it operates in. Consent, entity search, and furnish calls return403if your organization isn’t a member of thenetwork_idyou send. - Roles. Furnishing into a network requires the furnisher or governor role
in that network; otherwise the call returns
403. - Search. Entity search returns only subjects visible to you in the network you name, at most 100 per request, with no paging.
- Consent. A consent is bound to the network it was created in. A query
that uses it must include that network, or it returns
404. A query with an expired consent returns403. Consents can’t be deleted; to end a consumer consent early, set itsexpires_atwithPUT /v1/consent/consumer_identity/{consent_id}. Creating a consent requires you to attest that the subject’s consent was gathered first. - Profile-ID queries. A query can name the subject by profile ID instead of
a consent; the profile must be visible to you in the queried networks, or the
query returns
404. - Policy and entitlement. A query returns only the fields the network’s querying policy exposes and that your organization is entitled to see through its own participation.
- Not-found vs. not-visible. The API returns
404both for resources that don’t exist and for resources outside your reach; it doesn’t reveal which. - Error bodies. Unexpected server errors return a generic message and a request ID, without internal details.
Personal data the API returns
The API returns personal data only through the endpoints below, and only within the scoping above.
Some endpoints deliberately return no personal data values:
- Consent create, read, and update responses return the consent’s ID, grants, scope, and expiry — not the identity fields you submitted.
- The soft checks (
POST /v1/products/kyc_certificate_snapshot/query/soft,POST /v1/products/kyb_certificate_snapshot/query/soft) return only whether a certificate could be issued and which kinds of data are present or missing. - The coverage check (
POST /v1/products/check) returns per-furnisher, per-field yes/no coverage, not the values.
Third parties that process data
For the mapping
suggest and propose endpoints, only the structure of your
source data is sent by default. Sample values are sent only when you opt in:
mode: "structure_with_sample" on suggest, or
share_sample_with_model: true on propose.
This table covers third parties involved in API features. Ask your SOLO contact
for SOLO’s complete subprocessor list.