Welcome to the IPRO Public API.

You can use SwaggerUI to test requests.

There is a sample usage script in JavaScript. To run it you'll need node.js 14+ with axios package installed.

An example demonstrating advanced export workflows is also available.

Example scripts for chunked file upload are provided for PowerShell and bash.

To authenticate, a Public API client must be created in the IPRO Enterprise website, under System Manager. Only users in the "SuperAdmin" group can create Public API Clients.

The client_id and client_secret set, during the API client creation, can be used to obtain a token. (example script here)

APIs are secured using bearer JSON Web Tokens (JWTs), issued by IPRO Identity Server. The token is expected to be in the Authorization header of a request. The value is expected to have the bearer JWT.

Example header:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Tokens can be retrieved from the IPRO Identity Server using OAuth2.0 flow with client credentials grant type. The token endpoint can be found in the configuration discovery document. Example URL: https://<your_url>/auth/.well-known/openid-configuration.

API endpoints are documented with the scopes required to access. The scopes must be requested when sending the below client credentials request to IPRO Identity Server.

The below request example can be used to obtain a token. Replace Host, client_id, and client_secret with actual values.

POST /auth/connect/token HTTP/1.1
Host: example-site.ipro.com
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
&client_id=xxxxxxxx
&client_secret=xxxxxxxx
&scope=ipro.papi%20ipro.api%20ipro.superadmin

You can check what is the current version via OpenAPI description document's info.version value.

Typical version looks like v1.3, where:

• v1 is a major version. It corresponds to server URL prefix where API is accessible: https://<host>/v1/cases. It is incremented when the contract introduces any breaking changes.
• .3 is a minor version. It is incremented for non-breaking changes.

Special type is a preview version. For example, v1.0-preview.1 is a preview version for v1.0. Any changes between preview versions v1.0-preview.2 and v1.0-preview.1 might be backward incompatible.

All responses follow the format:

{
    "data": {},
    "error": {
        "code": "API0012",
        "message": "An error occurred. See logs for further details.",
        "exceptionMessage": "One or more errors occurred. (Failed to subscribe. ResponseErrorMsg=[Object cannot be cast from DBNull to other types.])"
    },
    "pagination": {}
}

• data is not present or null if there is an error
• error is not present or null if there is no error
• pagination is present only for paginated collections

Requests that return multiple results will be paginated to 100 items by default. You can use the pageNumber parameter to specify which page of data to retrieve. Pages start from 1.

To set page size, you use the pageSize query param. This sets the maximum page size. Please note that this does not guarantee that, that many items will be returned, even if there are more items than the maximum page size. It does guarantee that no more than the number provided will be returned.

API responses return pre-built pagination links first, prev, next and last and client applications are encouraged to follow these links for pagination.

All filtering for collections uses filter query parameter. Beware, not all collections support all filtering capabilities described in this section.

Example: &filter=name@=awesome title,jobType==imaging (items with a name that contains the phrase "awesome title" and jobType equals "imaging")

filter is a comma-delimited list of {Name}{Operator}{Value} where

• {Name} is the name of a property. You can also have multiple names (for OR logic) by using a pipe delimiter and parentheses, eg. (LikeCount|CommentCount) > 10 asks if LikeCount or CommentCount is >10
• {Operator} is one of the supported operators.
• {Value} is the value to use for filtering. You can also have multiple values (for OR logic) by using a pipe delimiter, eg. Title@=new|hot will return items with titles that contain the text "new" or "hot".

Notes:

• You can use backslashes to escape commas and pipes within value fields.
• You can have spaces anywhere except within {Name} or {Operator} fields.
• Nested objects can be referenced with periods . between property names, such as: queue.pending>=10.

Operators:

If not stated otherwise, the main method for update is using PATCH with JSON Merge Patch format. Refer to the brief explanation here.

You may notice that some fields are still required in update requests, for example schedule.type. Generally, this can be expected for fields in nested and/or polymorphic objects because we want to make sure that change is intentional and doesn't cause unexpected side-effects.

Some operations are marked as asynchronous, because they might require some time to complete. Such operations return operationLocation link in the response, which can be used to track operation status (see Operations for details).

Checking operation status via operation endpoint follows polling pattern. But we also support webhooks. The workflow is (for example, case creation):

1. Register webhook and subscribe to case creation events. (see User notifications for details)
2. Send request to create a case.
3. After case creation completion you'll be notified via webhook that case was created via event Enterprise.Case.Created (or if not, with the event Enterprise.Case.CreateFailed).

Most of the events can be traced back to the requests that triggered them via correlation id.

All v1.0.0 thru v1.2.0 interactions remain valid; only additions have been made.

• Added OCR. New endpoints:
  • /workflows/ocr
  • /workflows/ocr/{id}
  • /workflows/ocr/{id}/pause
  • /workflows/ocr/{id}/resume
  • /workflows/ocr/{id}/cancel

• Added reporting. New endpoints:
  • /reports/result/{id}
  • /workflows/{workflowType}/{id}/reports
  • /workflows/{workflowType}/{id}/reports/{reportId}
• Updated tags: Workflow Reports -> Workflow Status
• New event notification type: Enterprise.Report.Executed

• Added export management and workflows. New endpoints:
  • /exportSeries/{id}
  • /workflows/export/{id}
  • /workflows/export/{id}/pause
  • /workflows/export/{id}/resume
  • /workflows/export/{id}/cancel
  • /workflows/export/{id}/documents
  • /workflows/export
  • /cases/{id}/exportSeries
  • /cases/{id}/workflows/export

Modified Endpoints

POST /cases

• Request body updated
  • New property: capabilities.ingestion.baseCase.includeAllExportSeries
  • New property: capabilities.ingestion.exportErrorDocuments
  • New property: capabilities.ingestion.exportIntervalMinutes

GET /cases/{id}

• Modified response: 200
  • New property: data.capabilities.ingestion.activeExportSeriesId
  • New property: data.capabilities.ingestion.exportErrorDocuments
  • New property: data.capabilities.ingestion.exportIntervalMinutes

PATCH /cases/{id}

• Request body updated
  • New property: capabilities.eda.enabled
  • New property: capabilities.ingestion
  • New property: capabilities.review

GET /cases/{id}/workflows/ingestion and GET /workflows/ingestion

• Modified response: 200
  • New property: data.items[*].activeExportSeriesId
  • New property: data.items[*].documentCount

GET /workflows/ingestion/{id}

• Modified response: 200
  • New property: data.activeExportSeriesId
  • New property: data.documentCount

• Initial public release.

Use connectors to structure data ownership. There are several categories of connectors:

• live connectors (e.g., Box, M365, etc)
• archive connectors (used for storing data in NetGovern-specific format)

Allows uploading your own data for ingestion workflows.

To preserve data integrity, particularly document dates, only archive/container type files can be uploaded. An error will occur if you attempt to import a file that is not in an archive/container format. Allowed formats:

• File archives (such as .ZIP files)
• Mail archives (such as .PST files)
• Forensic image files (such as .E01 files)

The upload API provides a way to reliably upload large files using chunked uploads. Client application uploads a file in parts, allowing it to recover from a failed requests. Thus, an application needs to retry the upload of a single chunk instead of the entire file. We also support uploading chunks concurrently.

Chunked uploads require a sequence of API calls to be made:

1. Create an upload session
2. Upload chunks
3. Check upload status

APIs for managing case hierarchy, which is: Managing client > Client > Cases.

Cases API provide ability to create and manage cases.

APIs for managing export series in the context of a case's ingestion capability. Export series are added during case creation. If using a base case template with includeAllExportSeries property set to True, and creating a new client, the existing series from the base case's client will be copied. Otherwise, the existing series in the client will be available. If Ingestion and Review capabilities are enabled, then a default export series will be created to push data to Review. More than one case can reference the same export series under the same client.

Ingestion workflows can be configured to push data into a Review case, or to disk, or to Relativity (Load File).

Export workflows allow for advanced export of specific documents into a Review case, or to disk, or to Relativity (Load File).

Documents are provided to the export workflow.