Skip to main content
Minerva API access is managed from the Developers page in the Minerva dashboard. Access: Requires the Developer role or above. In the sidebar, go to Administration > Developers. Use this guide when you need to:
  • create a new live or dev application key for an integration
  • review existing application key prefixes, creators, and last-used activity
  • deactivate or delete unused keys without affecting other integrations
  • configure screening workflow webhooks for profile status updates
Create a separate application per environment, customer integration, or downstream service. That keeps key lifecycle actions, last-used timestamps, and audit context isolated for each integration.

​
Before You Begin

  • confirm you have a Developer, Admin, or Owner team role
  • decide whether the integration needs a Live or Dev application key
  • prepare a vault or secrets manager to store any newly created API key
  • if you plan to use webhooks, prepare an HTTPS endpoint that can validate the x-webhook-key header

​
Developers Page Overview

The Developers page combines two integration surfaces:
  • API Keys for issuing and managing application credentials
  • Webhooks for profile status update notifications

​
Create A New API Key

Minerva creates API keys through named applications. When you select Create application, Minerva asks for:
  • an application name
  • an optional description so your team knows what the key is used for
  • the application mode: Live or Dev

​
What To Expect After Creation

  • each application receives its own key lifecycle and usage tracking
  • the new plaintext key is shown only once, so store it immediately in your secrets manager
  • the table then keeps the key prefix, creator, created timestamp, and last used timestamp for later review
Use consistent application names such as Customer Gateway - Prod, Customer Gateway - QA, or Partner Sync - Sandbox so lifecycle actions stay obvious in audit and support workflows.

​
Manage Existing API Keys

Open an application row to review and manage its details. The management view lets you:
  • update the application name or description
  • review the current key prefix and historical key records
  • confirm who created the application
  • deactivate an application to stop downstream use immediately
  • reactivate or delete an application when appropriate

​
Screening Workflow Webhooks

Webhooks are currently for profile status update events only. They are intended to support tighter integrations and near-real-time notifications when you use Screening Workflow Profiles. Supported profile status values today are:
  • potential_match
  • accepted
  • rejected
This is most useful when your internal systems need to react as Minerva profiles move through review outcomes.
Webhooks do not replace the screening APIs. They complement a profile-based workflow by notifying your downstream systems when a Minerva profile changes status.

​
Create And Manage Webhooks

The Webhooks section lets you:
  • name each webhook destination clearly
  • choose which profile status values should trigger notifications
  • copy the generated webhook key for receiver-side validation
  • test the destination before relying on it in production
  • edit or delete old destinations as integrations change

​
Best Practices

  • create one application key per integration and environment instead of sharing a single key broadly
  • rotate or deactivate keys when an integration is retired or ownership changes
  • store API keys and webhook keys in a secrets manager, not in source control
  • use webhook names that identify the receiving system and environment clearly
  • validate the x-webhook-key header on every webhook delivery