Coverage Check

The coverage check is a non-billable, read-only utility. Given a product, a subject, and a set of networks, it reports per furnishing institution which of the product’s fields that institution has furnished for the subject, and whether the subject’s consent covers them. It does not issue a certificate, return subject data values, or record a billable query event.

POST /v1/products/check

One endpoint serves every product: pass the product_id of the product you want to check.

The response names the furnishing institutions in the queried networks (furnishing_entity_name) and shows which of them hold data on the subject (hit). Treat it with the same care as any other information about the subject.

Coverage check vs soft check

	Coverage check	Certificate soft check
Endpoint	`POST /v1/products/check`	`POST /v1/products/{kyc,kyb}_certificate_snapshot/query/soft`
Answers	Which institutions have furnished which fields for this subject?	Would this exact certificate query issue a certificate right now?
Applies the querying policy’s filters	No. Any furnished, non-empty value counts.	Yes. Same resolution as the billable query.
Breakdown	Per furnishing institution, per model, per field	`issuable`, `missing_data_paths`, `matched_models`
Billable	No	No

Because the coverage check ignores the policy’s freshness and other filters, a complete coverage row does not mean a certificate query will return 200, and an incomplete one does not mean it will return 204. To predict the query outcome, use the soft check.

Request

curl -X POST https://api.sandbox.solo.one/v1/products/check \
  -H "Authorization: Bearer $SOLO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "3e8a1d5f-…",
    "consent_id": "a3f0b9c7-…",
    "network_ids": ["9f1c0c2e-…"]
  }'

Field	Type	Required	Purpose
`product_id`	UUID	yes	The product to check.
`consent_id`	string	one of¹	Consent token identifying the subject.
`consumer_identity_id`	UUID	one of¹	Direct consumer profile reference (for consumer products).
`business_identity_id`	UUID	one of¹	Direct business profile reference (for business products).
`network_ids`	UUID[]	yes	Networks to check across.
`furnishing_entity_ids`	UUID[]	no	Only report these institutions. When omitted, every member institution of the queried networks is reported.

¹ Identify the subject the same way you would on the query itself: a consent_id, or the direct profile id matching the product’s subject (consumer_identity_id for consumer products, business_identity_id for business products).

Response

A 200 OK with one entry per member institution of the queried networks (institutions that hold data for the subject first):

{
  "product_id": "3e8a1d5f-…",
  "consumer_identity_id": "c2a4e8d0-…",
  "business_identity_id": null,
  "entities": [
    {
      "furnishing_entity_id": "e1d2c3b4-…",
      "furnishing_entity_name": "First Example Bank",
      "network_id": "9f1c0c2e-…",
      "complete": false,
      "hit": true,
      "models": [
        {
          "model_name": "DocumentCaptureEvent",
          "hit": true,
          "met_count": 2,
          "consented_count": 7,
          "total_count": 7,
          "fields": [
            { "field_name": "is_document_captured", "met": true, "consented": true, "consent_governed": true },
            { "field_name": "document_capture_timestamp", "met": true, "consented": true, "consent_governed": true },
            { "field_name": "document_capture_method", "met": false, "consented": true, "consent_governed": true }
          ]
        },
        {
          "model_name": "LivenessCheckEvent",
          "hit": false,
          "met_count": 0,
          "consented_count": 0,
          "total_count": 9,
          "fields": [
            { "field_name": "is_liveness_captured", "met": false, "consented": false, "consent_governed": true }
          ]
        }
      ]
    }
  ]
}

The example is abridged; each model lists all of its fields.

Field	Meaning
`entities[]`	One row per member institution of the queried networks (or per institution in `furnishing_entity_ids`). Institutions holding data for the subject come first.
`entities[].furnishing_entity_name`	The institution’s name.
`entities[].network_id`	A queried network the institution is a member of.
`entities[].hit`	Whether this institution holds any data for the subject in this product.
`entities[].complete`	Whether this institution has furnished every field of every model listed.
`entities[].models[]`	Per-model breakdown, keyed by the product’s model names (see each product’s field reference).
`models[].hit`	Whether the institution has any record of this model for the subject.
`models[].met_count` / `total_count`	How many of the model’s fields the institution has furnished a non-empty value for, out of the total.
`models[].consented_count`	How many of the model’s fields the subject’s consent covers for this institution.
`models[].fields[].met`	Whether the institution furnished a non-empty value for this field.
`models[].fields[].consented`	Whether the subject’s consent covers this field for this institution. Consent is granted per model, so every field of a model shares the same value.
`models[].fields[].consent_governed`	Whether this field’s data can be granted by a subject consent at all, as opposed to operational or audit data.

The field_name values match the product’s field reference tables; see the KYC certificate and KYB certificate pages. Identifier fields (attestation_event_id, furnishing_entity_id) are not counted. The coverage check resolves the subject the same way the query does, so it returns the same 400, 403, and 404 errors (see Query failure modes). An unknown product_id also returns 404 RESOURCE_NOT_FOUND.

When to use it

Choosing a scope. The per-institution breakdown shows who holds the subject’s data, so you can target furnishing_entity_ids or pick the right network before querying.
Planning data collection. Fields no institution has furnished are the ones you will need to collect yourself.
Checking consent coverage. consented and consented_count show where the subject’s consent does and doesn’t reach.

What it does not do

The coverage check does not:

apply the querying policy’s filters, so it does not predict whether a certificate query will return 200 or 204 (use the soft check for that);
issue a certificate or return subject data values, only coverage flags and counts;
record a billable query event.

Querying

The billable product queries.

Products

The catalog of products you can check and query.

Furnishing API

Query API

GraphQL API

Coverage check vs soft check

Request

Response

When to use it

What it does not do

Querying

Products

​Coverage check vs soft check

​Request

​Response

​When to use it

​What it does not do

​Related

Querying

Products

Coverage check vs soft check

Request

Response

When to use it

What it does not do

Related