Skip to main content
The Minerva API enables financial institutions and regulated entities to automate and streamline key parts of their anti-money laundering (AML) compliance workflows. It leverages advanced deep learning models to analyze and consolidate information from over 250,000 global sources, covering nearly 1 billion individuals and entities and over 4.5 billion data points. The API provides structured outputs to support screening, investigations, onboarding, and regulatory reporting.
⚠️ URL Migration Notice: Legacy *.minervaai.io URLs are deprecated. Use the *.gominerva.com URLs shown throughout this API reference for all new integrations.

Getting Access

Access to the Minerva API is managed through the Minerva dashboard:
  • API keys are created and managed from Administration > Developers. This page requires the Developer role or above.
  • Create separate live and dev applications so each integration has its own key lifecycle, usage history, and owner context.
  • For additional access or integration requests, please contact support@gominerva.com.
  • API keys are not currently scoped by per-key RBAC permissions.

API Overview

The Minerva API is organized around two key capabilities:
  1. Profile Management
  2. Real-Time Risk Assessment
This guide walks through the features and workflows of each.

1. Profile Management & Monitoring

  • Integrate Minerva into onboarding workflows to screen and register customers in a single step.
  • Keep customer profiles up to date and synchronize data across internal systems and Minerva.
  • Enable ongoing monitoring for changes in risk status or new matches.
  • Leverage APIs and webhooks to support investigation workflows, review queues, and keep internal systems in sync

2. Real-Time Risk Assessment

Minerva screens individuals and entities against global watchlists (e.g. sanctions, PEPs, criminal, terror lists) and adverse media mentions. Results are enriched with supporting evidence and confidence scoring.
  • Real-Time Screening: Instantly screen a single profile synchronously for immediate results.
  • Batch Screening: Submit large batches of profiles to be processed in parallel asynchronously, supporting high-volume operations.
  • Generate reports: Automatically summarize search results and profile data for documentation, audits, or compliance filings.

Interpreting Screening Results

Each object in a search response’s results[] array is a ranked potential match. It is evidence for review, not a confirmed identity match or an automatic compliance conclusion. Use three separate questions when mapping the response into a compliance workflow:
A match score is not the probability that a subject is sanctioned, politically exposed, or risky. For example, score: 0.92 means the candidate matched the submitted identity criteria strongly; it does not mean “92% sanctioned.”

High-Level Sanctions Example

The following abbreviated example shows the fields an integration normally uses first. The values are illustrative.
In this example:
  1. checklist.screen.Sanctions: true is the direct risk indicator.
  2. score: 0.94 says the candidate is a strong overall criteria match.
  3. checklist.hits.Sanctions identifies the list that triggered the flag.
  4. checklist.hits_info[] shows that the name is close and the reported date is exact.
  5. source_details[] provides the source description, URLs when available, and any supporting inference context.
The analyst should still compare all available identifiers and source evidence before dispositioning the candidate as a true positive, false positive, or unresolved.
See the Screening Integration Guide for the complete response hierarchy, Sanctions/PEP/News mappings, score and closeness interpretation, consensus and source-lineage fields, profile-linked search history, and recommended analyst review order.
Use POST /v1/reports with a searchResultId from a previous search.
The abbreviated responses below only show the fields you need to carry from one step to the next: jobid, searchId, searchResultId, index, and reports.

Single Search Flow

Step 1: Run POST /v1/search-sync Request:
Response:
Save searchId. For search-sync, this value becomes searchResultId in the report-generation request.
Step 2: Run POST /v1/reports with that searchId Request:
Response:
index selects the ranked match from the prior search response: 0 for the top match, 1 for the second match, and so on.

Batch Search Flow

Step 1: Run POST /v1/search Request:
Response:
Save id from this response. This is the batch jobid you use to read the completed results.
Step 2: Read the completed batch results You can use either POST /v1/searchStatus or GET /v1/search/{jobid}. The examples below use POST /v1/searchStatus. Request:
Response:
Each results[n].searchId is entity-scoped. Pick the searchId for the subject you want to report on, then pass that value as searchResultId.
Step 3: Run POST /v1/reports with the batch result searchId Request:
Response:

Summary

With Minerva’s API’s you can:
  • Screen individuals and entities in real time or as part of a batch
  • Integrate screening and monitoring into onboarding and compliance workflows
  • Monitor and manage customer profiles over time
  • Generate audit-ready reports for documentation and regulatory filings
  • Streamline and scale your AML compliance operations