API integration overview

Innovatrics ABIS Criminal Investigation exposes a comprehensive REST API for integration with third-party systems. The API allows agencies to wire their existing case-management, RMS, RPA and intelligence platforms directly into the forensic backend without having to use the standard forensic UI.

This chapter explains the structure of the API surface, the conventions used across all endpoints and gives quick links to the per-area documentation.

Service layout

The Criminal Investigation product exposes its functionality through one primary HTTP service, the Investigation Service, complemented by two infrastructure services that are shared with the rest of the ABIS platform:

Service	Purpose	Notes
Investigation Service	Cases, Evidences, Examinations, Hits, Snapshots, Visual Annotations, Migration.	The primary integration target for criminal use cases.
Integration Service (Civil API)	Applicant CRUD, biometric identification and verification, hitlists, configuration.	Used to manage criminal records (applicants), galleries and biometric matching.
Authorization Service	OAuth2 authentication, user and role management.	Used by every other service.

The exact base URLs depend on the deployment topology. In a typical on-premise deployment all services are exposed behind one shared API gateway:

https://<abis-middle-tier-url>/investigation/...
https://<abis-middle-tier-url>/civil/...
https://<abis-middle-tier-url>/authorization/...

API conventions

Resource-oriented design

Every API follows REST conventions:

• PUT /resources/{id}/create to create a resource with a client-chosen identifier,
• GET /resources/{id} to read a resource,
• PUT /resources/{id}/update to update a resource,
• POST /resources/{id}/delete to soft-delete a resource,
• DELETE /resources/{id} to permanently delete a resource (when supported).

Identifiers

Every resource uses client-supplied UUIDs. This makes integration with third-party systems much easier – the calling system can generate the identifier locally and use it both in ABIS and in its own database.

Headers

Every request must include the following headers:

Header	Purpose
Authorization: Bearer <token>	OAuth2 access token.
X-User-ID	The user on whose behalf the request is performed.
X-Transaction-ID	A correlation identifier for the request – appears in the audit log and the response.
Innovatrics-Request-Id	A unique request identifier for idempotency.

Idempotency

Every write operation is idempotent: a repeated request with the same Innovatrics-Request-Id returns the result of the original request without performing the operation a second time.

Settings override

A handful of platform-level settings (matching threshold, candidate count, persistence policy, etc.) can be overridden per request through a dedicated settings object in the request body.

Errors

Errors are returned as standard HTTP status codes with a structured JSON body containing an error code, an error message and (where useful) a list of validation issues. The full list of error codes is part of the OpenAPI definition.

Code samples

The samples in this documentation are written in C# and Java, using the client code generated from the OpenAPI definition at editor.swagger.com. Other languages – Python, JavaScript, Go – work in exactly the same way; the only differences are language-specific syntax. The OpenAPI specification can be downloaded directly from the Investigation Service.

Where to start

• Authentication – how to obtain an OAuth2 access token.
• Criminal records (Applicants) API – how to manage records of known persons.
• Cases API – how to create, read, update and delete cases.
• Evidences API – how to manage forensic evidence.
• Examinations API – how to run the ACE-V workflow programmatically.
• Hits API – how to read and write forensic decisions.
• Visual Annotations API – how to manage annotations and their links.
• Identification and Verification API – how to invoke biometric matching.
• Notifications and callbacks – how to subscribe to asynchronous events.