Notifications and callbacks

Many forensic workflows are inherently asynchronous: video processing takes minutes to hours, identification jobs queue behind one another, deduplication runs in the background and ACE-V verification happens whenever the verification examiner gets to it. Innovatrics ABIS exposes both callback notifications (push) and status endpoints (pull) so that integrating systems can stay in sync without blocking on long-running calls.

Callback notifications

The Integration Service can deliver REST callbacks to a URL configured per integration client (or per request). The payload is a small JSON document carrying:

• the event type (evidence.processed, examination.status.changed, hit.created, hit.deleted, case.updated, applicant.deduplicated, etc.),
• the resource identifier (case ID, evidence ID, examination ID, hit ID, applicant externalId),
• the timestamp,
• the user and the transaction ID that originated the change,
• a small payload with the new state (no binary data – the receiver fetches the full resource via the corresponding GET endpoint).

The receiver must respond with HTTP 2xx to acknowledge the notification. The Integration Service retries failed deliveries with exponential back-off and persists every delivery attempt for audit.

Subscribing

Callback URLs and the event types they listen for are configured per OAuth2 client in the Authorization Service. Per-request callbacks can be supplied through the callbackUrl field of long-running operations (for example video processing or migration import).

Pull-mode polling

Where push notifications are not possible (firewalls, on-premise integrations) the integrating system can poll the status endpoints:

Endpoint	Purpose
GET evidences/{evidenceId}/status	Returns the full ACE-V status history of an evidence.
GET examinations/{examinationId}/status	Returns the full ACE-V status history of an examination.
GET cases/{caseId}	Returns the case with all related evidences and aggregated hit counts.
GET applicants/{externalId}	Returns the current state of a criminal record, including its lifecycle status.

Polling can be combined with conditional GETs (If-Modified-Since) to minimise traffic.

Idempotency and ordering

Callbacks may arrive out of order or be duplicated. Receivers should be idempotent: the same notification, processed twice, must produce the same outcome. Every notification carries a Innovatrics-Request-Id header that uniquely identifies the originating request and can be used as a deduplication key.

Sample – minimal callback receiver in ASP.NET

[ApiController]
[Route("/abis/callback")]
public class AbisCallbackController : ControllerBase
{
    [HttpPost]
    public IActionResult Receive([FromBody] AbisNotification notification)
    {
        // Process the notification idempotently.
        _store.Save(notification.RequestId, notification);
        return Ok();
    }
}

Sample – minimal callback receiver in Spring Boot

@RestController
@RequestMapping("/abis/callback")
public class AbisCallbackController {

    @PostMapping
    public ResponseEntity<Void> receive(@RequestBody AbisNotification notification) {
        store.save(notification.getRequestId(), notification);
        return ResponseEntity.ok().build();
    }
}