Skip to main content
This guide covers advanced operations for managing Alerts and Cases - including batch creation, bulk assignments, status updates, escalation, and entity associations. Full API endpoint details are available in the API Reference (requires API credentials).
For basic alert and case creation, see the Ingesting Alerts & Cases guide first.

Alerts

Get an Alert

Endpoint: GET /v1/alerts/{alertId} Retrieve a single alert by its Corsa ID.

Step 1: Batch Create Alerts

Endpoint: POST /v1/alerts/batch Create up to 50 alerts in a single request. Each alert in the array follows the same schema as the single-create endpoint.
Maximum 50 alerts per batch request. Set upsert: true to update existing alerts matched by referenceId.

Step 2: Bulk Update Alerts

Endpoint: PATCH /v1/alerts/bulk/update Apply the same field changes to up to 100 alerts in one request. Use this when you need to set the same priority, category, or custom fields across a group of alerts.
Maximum 100 alerts per request. Only the fields in update are modified; all other fields remain unchanged.

Step 3: Update an Alert

Endpoint: PUT /v1/alerts/{alertId}/update Update any field on an existing alert - priority, status, assignee, associated entities, and more.

Alert Statuses

Alert Categories


Step 4: Bulk Assign Alerts

Endpoint: PATCH /v1/alerts/bulk/assign Assign or unassign up to 100 alerts at once.
Omit assigneeId or set it to null to unassign alerts.

Step 5: Bulk Update Alert Status

Endpoint: PATCH /v1/alerts/bulk/status Update the status of up to 100 alerts at once, with an optional decision reason.

Step 6: Bulk Escalate Alerts to Cases

Endpoint: PATCH /v1/alerts/bulk/escalate Escalate multiple alerts to cases in a single request. Each alert gets its own case.

Step 7: Associate Entities with Alerts

Link clients or transactions to an existing alert. Associate clients: PUT /v1/alerts/{alertId}/clients The request body is a plain JSON array of client IDs.
Associate transactions: PUT /v1/alerts/{alertId}/transactions

Cases

Get a Case

Endpoint: GET /v1/cases/{caseId} Retrieve a single case by its Corsa ID.

Step 8: Batch Create Cases

Endpoint: POST /v1/cases/batch Create up to 50 cases in a single request. Each case in the array follows the same schema as the single-create endpoint.
Maximum 50 cases per batch request.

Step 9: Update a Case

Endpoint: PUT /v1/cases/{caseId}/update Update case details, reassign, change priority, or link additional entities.

Case Statuses


Step 10: Bulk Update Cases

Endpoint: PATCH /v1/cases/bulk/update Apply the same field changes to up to 100 cases in one request.
Maximum 100 cases per request. Only the fields in update are modified; all other fields remain unchanged.

Step 11: Bulk Assign Cases

Endpoint: PATCH /v1/cases/bulk/assign Assign or unassign up to 100 cases at once.

Step 12: Bulk Update Case Status

Endpoint: PATCH /v1/cases/bulk/status

Step 13: Bulk Update Case Reviewers

Endpoint: PATCH /v1/cases/bulk/reviewers Manage reviewers across multiple cases with three modes: SET (replace all), ADD (append), or REMOVE.

Step 14: Associate Entities with Cases

Link alerts, clients, or transactions to an existing case. Associate alerts: PUT /v1/cases/{caseId}/alerts All case association endpoints accept a plain JSON array of IDs as the request body.
Associate clients: PUT /v1/cases/{caseId}/clients
Associate transactions: PUT /v1/cases/{caseId}/transactions

Screening Matches

Screening alerts — those with a category of SCREENING_SANCTIONS, SCREENING_PEP, or SCREENING_ADVERSE_MEDIA — can carry one or more matches: the specific list entries or profiles that triggered the alert. The endpoints below let you attach, update, and record decisions on those matches.
Match endpoints apply only to screening-category alerts. Calls against other alert categories are rejected.

Attach Matches to an Alert

Endpoint: POST /v1/alerts/{alertId}/matches Add one or more screening matches to an existing alert. Useful when a vendor delivers match data asynchronously after the alert is already created, or when your system appends additional matches.

Match Fields

Up to 100 matches can be attached in a single call.

Update a Match

Endpoint: PATCH /v1/alerts/{alertId}/matches/{matchId} Update the profile fields on a match before a decision has been recorded — for example, when the vendor delivers an updated profile with more detail.
Updates are rejected after a decision has been recorded on the match.

Record a Decision on a Match

Endpoint: POST /v1/alerts/{alertId}/matches/{matchId}/decision Record whether a single match is a true positive or a false positive.

Decision Fields


Record a Bulk Decision

Endpoint: POST /v1/alerts/{alertId}/matches/bulk-decision Apply the same decision to multiple matches on a single alert in one request.

Request Fields


Remove a Match

Endpoint: DELETE /v1/alerts/{alertId}/matches/{matchId} Remove a wrongly-attached match — for example, a duplicate delivered by a vendor retry. The client’s screening status is recomputed after deletion.
Deletion is rejected if a decision has already been recorded on the match.

Get Alerts by Entity

Endpoint: GET /v1/alerts/entity/{entityType}/{entityId} Retrieve all alerts associated with a specific client, transaction, or case. Use this endpoint instead of relying on embedded alerts fields returned on entity responses — those fields are deprecated.

Path Parameters

Query Parameters

Response

Returns a paginated list of AlertDto objects associated with the entity.

What’s Next?

Transaction Monitoring

Set up transaction monitoring rules and evaluate transactions.

Manage Attachments

Upload and link files to alerts, cases, and other entities.