Individual · born 1984 · Canada
No list returned a hit above threshold.
Developers
POST a subject and the feeds to run. Minerva returns ranked potential matches, each with its score, the risk flags that fired and the sources behind them. Entity matching reads every hit in context, so your review queue takes up to 75% fewer false positives.
1.2 sIndividual · born 1984 · Canada
No list returned a hit above threshold.
Individual · born 1971 · Cyprus
OFAC SDN List · name and country context agree.
Entity · incorporated 2014 · Singapore
PEP register · one officer in common, no identifier match.
Coverage
Three feeds, one request. You pick which of them a given search runs, per call or per workspace, and Minerva resolves the results into one entity before it scores anything.
Screen against sanctions lists from 197 list-issuing jurisdictions, refreshed daily and matched using identity context.
Lists are the floor. Minerva also reads open-source media, then grades the exposure so your policy decides what is worth an alert.
Real-time web search with sentiment analysis, so a name that appeared in this morning's reporting is not waiting for a list refresh.
The request
Screening is synchronous: the 200 carries the result itself, not a job id to poll, so the call can sit in your onboarding path rather than behind a queue. It returns up to ten ranked potential matches, each with the source lineage you will need when an examiner asks where a value came from.
Browse Minerva docsPOST /v1/search-sync HTTP/1.1
Host: api.gominerva.com
Content-Type: application/json
x-api-key: $MINERVA_API_KEY
{
"type": "individual",
"name": "John Example",
"year": 1970,
"country": "Canada",
"feeds": ["Sanctions", "PEP", "News"]
}
The call is authenticated with an x-api-key header, and the body that comes back is the screening itself rather than a receipt for one. type echoes the request's subject as its numeric code. Keep the searchId: passed as searchResultId to POST /v1/reports, it generates the PDF audit export for this search.
results holds the ranked potential matches. Each one is a profile, and the name block quotes the value that matched with its own match_score and criteria_match_level.
score is the overall Criteria Match Score from 0 to 1. The API reference describes 1.0 as exact, 0.80 to 0.99 as partial, and scores below 0.80 as low confidence. Field-level values such as name.criteria_match_level use the labels exact, close, loose, or none.
checklist.screen answers the request's own feeds array: Sanctions, PEP, News and the rest, each one true or false for this match.
review_status is the state your workflow reads. In Hint Mode, disposition_hint adds the advisory prediction, confidence and rationale while sources carries the lineage behind the profile.
{
"status": "success",
"code": 200,
"duration": 1.2,
"searchId": "b426f9b4-17ed-4f31-a39d-c49f45c753f0",
"type": 0,
"page": 1,
"pageSize": 10,
"count": 1,
"results": [
{
"name": {
"value": "John Example",
"match_score": 0.97,
"criteria_match_level": "close"
},
"score": 0.97,
"checklist": {
"screen": { "Sanctions": true, "PEP": false, "News": false }
},
"review_status": "unresolved",
"disposition_hint": {
"prediction": "true_positive",
"confidence": 0.99,
"analysis_status": "completed",
"rationale": "The searched subject matches the potential match on name and country context, and no discovered identity attribute contradicts the match."
},
"sources": ["OFAC SDN List"]
}
]
}
The fields most likely to become branches, records or analyst context in your integration.
| Field | Type | What it carries | Permalink |
|---|---|---|---|
searchId | string | Pass it as searchResultId to POST /v1/reports to generate the PDF audit export for this screening. | # |
type | number | Subject type. The request takes the word (individual) and the response returns the numeric code (0) for that same subject. | # |
score | number | The overall Criteria Match Score from 0 to 1. The API reference describes 1.0 as exact, 0.80 to 0.99 as partial, and scores below 0.80 as low confidence. Field-level values such as name.criteria_match_level use exact, close, loose, or none. | # |
checklist.screen | object | Which risk feeds fired for this match: Sanctions, PEP, News and the rest, each true or false. | # |
review_status | string | not_found, unresolved, true_positive, false_positive or suppressed. New matches start unresolved. | # |
automatic_disposition | object | The prediction applied in Full Auto Mode when a match carries a risk flag. | # |
disposition_hint | object | The advisory prediction in Hint Mode, with its confidence, analysis_status and rationale. | # |
sources | string[] | Every source that contributed data to the profile, which is the lineage an examiner asks for. | # |
Source: Minerva Core API reference. Payloads are trimmed from the published examples.
What you get
Minerva matches structured and unstructured data to your customer in context rather than on name similarity, so your team is not making those comparisons by hand.
Bring the payload you would actually send. In the demo we run it against your own list configuration and walk the response field by field, including the disposition annotations your integration would branch on.
