Skip to main content
Version: Next

Asynchronous API Overview

Until release 2.3.0 of the CDR Platform a synchronous API model was provided, necessitating the requester to await the allocation of resources to fulfill the request.

While the Synchronous API effectively meets the need for handling substantial volumes of data, certain client architecture patterns will require the incorporation of an asynchronous mode. Through the Asynchronous API, requests undergo a two-stage process. Initially, a UUID is generated for a request, which can subsequently be used to retrieve the processing outcome. This enables the client to continue at its own convenience, eliminating the requirement to wait for file processing.

Comparison with the Sync API​

API​

API Documentation.

Adhering to best practices for Asynchronous APIs, requests undergo a two-stage process. To provide a conceptual analogy, imagine the Sync API's CDR endpoint split into two.

For example: In the Sync API, a POST request made to the CDR endpoint (api/v3/cdr) becomes:

  1. a POST to api/v1/cdr-async
    • The response body will contain a newly created UUID: 
      {
        "transactionId": "ee7b1c04-dade-4abf-b5db-5e3f13b06c2d"
      }
  2. followed by a GET to api/v1/cdr-async/{transactionId}.
    • The response will contain the rebuilt file and analysis report in the same composite Zip format as returned by the Sync Api.

Supported File Types​

The Asynchronous API shares compatibility with the file types also supported by the Synchronous API, listed in Supported File Types.

The handling of archives and archive processing mirrors that of the Sync API, with detailed information available in Archive Support.