Skip to main content
The coverage check is a non-billable, read-only pre-flight for product queries. Given a product, a subject, and a network + policy scope, it reports — per furnisher — which of the policy’s required fields are covered by data already furnished to the network. It answers “if I run this query now, can it succeed?” without issuing a certificate, recording a query event, or creating a billable event.
CategoryUtility (not a product query)
Use casePre-flight a query, avoid predictable 204s
SubjectConsumer or business (matches the checked product)
FamilyNon-billable check
OperationPOST /v1/products/check
One endpoint serves every product: pass the product_id of the product you intend to query.

​
Why it exists

A product query that resolves but cannot satisfy the policy returns 204 No Content — and that resolved query is still a billable event. The coverage check lets you avoid predictable 204s for free.

​
At a glance

curl -X POST https://api.solo.one/v1/products/check \
  -H "Authorization: Bearer $SOLO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "product_id": "3e8a1d5f-…",
    "consent_id": "a3f0b9c7-…",
    "policy_id": "5e7d2a14-…",
    "network_ids": ["9f1c0c2e-…"]
  }'
A 200 OK returns one entry per furnisher that has relevant data, each with a complete flag and a per-model, per-field breakdown of which requirements are met. The field_name values trace directly to each product’s field reference.
The coverage check is a soft check. It does not issue a certificate, return subject data, record a query event, or guarantee the subsequent query returns 200 — data can change between the check and the query.

Full request & response schema

The complete coverage check deep dive — full request fields, the response shape, and when to use it.

Products

The full product catalog.

Querying

The billable query the coverage check pre-flights.