The catalog
Four products are queryable today. The exact set available to you depends on the networks you belong to.
They fall into two families:
- Certificates are consolidated, multi-attribute verification results
assembled from data furnished by network participants. Querying one can
issue a reusable certificate for the subject. Certificate queries return
204 No Contentwhen the available data cannot satisfy the policy. - Screening lists are read-only yes/no checks against lists of flagged
individuals. They return a listing indicator plus a small set of context
fields, never a certificate — and always
200 OK, with a clean result expressed as"is_listed": false.
The query / furnish pattern
Query
Read consolidated data for an entity, drawn from what authorized
participants have furnished. Requires a consent ID
or a direct profile reference.
Furnish
Contribute verified data for an entity into a network, making it available
for future queries by entitled participants.
POST /v1/products/check, the non-billable
coverage check, which reports whether the
furnished data for a subject can satisfy a policy before you run a billable
query.
How products relate to networks and policies
A product defines what data exists — its models, fields, and types. A network decides which products it offers to its members. A querying policy defines, per network, which parts of a product a query may read and under what conditions (e.g. how recent a verification must be). The same product can behave differently in two networks because each network attaches its own policies. This is why every query carries bothnetwork_ids and a policy_id: the
product determines the endpoint and response schema, while the network + policy
scope determines what actually comes back. What you’re
entitled to read narrows it further.
Each product’s schema is defined as a set of models — named groups of typed
fields such as DocumentCaptureEvent or BusinessRiskComplianceEvent. These
model and field names are the shared vocabulary across the platform: policies
select them, the coverage check reports
against them, and the per-product field reference tables document them. When a
policy “requires liveness within 30 days,” it is expressing a filter over a
product model’s fields — the same fields you’ll see in the query response.
Querying a product
A product query reads consolidated data for one entity. It needs a consent ID (or direct profile id) identifying the subject, and a network + policy scope:200 vs 204 semantics, the X-Ref-Id audit header, and billing notes.
Furnishing a product
Furnishing contributes one or more records for an entity into a network:Choosing a product
In practice these compose: an onboarding flow might run both screening lists
first, then a coverage check, then the KYC certificate query — three billable
list/certificate queries at most, with the free check deciding whether the
certificate query is worth running.
In the dashboard
Products catalogue — By Templates
Products catalogue — By Attributes tab
Run query — choose KYC certificate product
KYC product detail — overview
KYC product detail — Querying Policies tab
Run query opened from product detail
Run query — choose KYB certificate product
Product deep dives
KYC Certificate
Consolidated consumer identity verification — nine sub-products, full field
reference.
KYB Certificate
Business identity, ownership & control, and risk/compliance in one
certificate.
Screening Lists
Bank-specific bad actor and cross-bank financial crimes watch lists.
Coverage Check
Non-billable pre-flight: can this query succeed under this policy?