Director Console API¶

Non-Breaking Changes¶

• A new resource or API endpoint

• A new optional parameter

• A new optional key in the JSON POST body

• A new key returned in the JSON response body

Breaking Changes¶

• All changes except the non-breaking mentioned above. For example,

• A new required parameter

• A new required key in POST body

• Removal of a mandatory property (a key that is mandatory when creating the entity) from the response

• Renaming a property in a response. For example: changing ‘device_name’ to ‘name’

• Changing a response to respond with an unexpected type. For example: changing ‘hostname’ type from String to List

• Removal of an existing endpoint

• Removal of an existing endpoint request method

• A substantially different internal behavior of an API call – such as a change to the default behaviour

General Guidelines¶

• Do safely ignore unknown and unexpected data in API responses

• Do safely ignore additional fields and object attributes in API responses

• Some services MAY add fields to responses without changing versions numbers. Services that do so MUST make this clear in their documentation and clients MUST ignore unknown fields

• Avoid relying on the order in which data appears in API JSON responses, unless order is explicitly defined as part of the service contract.

• Make sure that you call the RefreshList endpoint (if provided) for all the APIs after making updates to the configuration. This is to ensure that the API returns the latest data while using Get or List endpoints.

API Usage Guidelines¶

1. How to obtain Bearer Token?

   Bearer token can be obtained from Director Console’s left navigation bar’s Profile tab by clicking on Generate Token option. The token is valid only for 8 hours from the time it is generated. For times when the script runs for an extended period, you can use the Refresh Token API to obtain the new token automatically once the existing token expires.

2. How to obtain pool_UUID of the Fabric-enabled LogPoint?

   The value of the pool_UUID parameter can be obtained by logging into the Logpoint Search Master(LPSM) and navigating to the Settings >> Configurations >> LogPoint Pool section. Here a list of LPSM pools are displayed, and you can select the pool_UUID(UUID) by their Pool Name from the UUID column.

3. How to obtain logpoint_identifier?

   The value of the logpoint_identifier parameter be obtained by logging into Logpoint Search Master(LPSM) and navigating to the Settings >> Configurations >> LogPoint Pool section. You can find the details of all Fabric-enabled LogPoints associated with the pool by clicking on the Details icon under the Actions column. Click on the Details icon and find the name of your LogPoint and its identifier.

4. Since add, edit and delete operations are asynchronous, it might take some time to process them. Hence, a GET request might not always return the latest data. Also, if a Director console API request (PUT/POST/DELETE) is successful, it will return a JSON with a success message. It will also have a key called ‘message’ with an endpoint URL as value. Making a GET request to this URL will give the status of the request and response.

Request¶

POST

https://api-server-host-name/configapi/{pool_UUID}/{logpoint_identifier}/Incidents/{id}/fetchIncidentData

Example of a request body:

{
    "data": {}
}

Response¶

{
    "status": "Success",
    "message": "/monitorapi/{pool_UUID}/{logpoint_identifier}/orders/{request_id}/{data_node}-Logs/fetchLogData"
}

Monitoring API Request¶

Use the URL from the message field to check response status.

GET

/monitorapi/{pool_UUID}/{logpoint_identifier}/orders/{request_id}/{data_node}-Logs/fetchLogData

Understanding Monitoring API Responses¶

The Monitoring API returns one of three response states:

1. completed

The request has finished processing, and the response payload appears in the "response" object. The "success" field inside the response indicates whether the operation was successful:

• "success": true - The operation completed successfully.

• "success": false - The operation failed.

Example of a successful response:

{
    "request": {},
    "logpoint_identifier": "2ea932a7bxxxxxxxxxxxxxxxxx34",
    "pool_uuid": "4e78450xxxxxxxxxx867a",
    "response": {
        "success": true,
        "rows": [
            {
                "log_ts": 176xxxxx44,
                "_participating_events": [
                    {
                        "msg": "2025-11-04 09:19:00.86300 IndexSearcherBenchmarker; indexing speed; service=indexsearcher__logpoint; number_of_indexed_logs=0; time=60 s; indexing_mps=0; thread=Thread-2",
                        "log_ts": 17xxxxxx40,
                        "_type_str": "msg col_type device_name collected_at device_ip source_name _tz _enrich_policy device_address label norm_id service thread action object _fromV550 repo_name logpoint_name",
                        "device_name": "localhost",
                        "number_of_indexed_logs": "0",
                        "_offset": 133419,
                        "logpoint_name": "LogPoint"
                        // ...
                    }
                ]
            }
        ]
    }
}

2. in_progress

The request is being processed, and the "response" object either remains empty or contains partial data. In this case, the response includes an "in_progress": true field. Continue calling the Monitoring API until you receive the completed response where the response object is populated and the in_progress field is absent.

Example of a request in progress:

{
    "request": {
        "data": {
            "id": "688bxxx"
        },
        "action": "/Incidence/get_alert_context_data",
        "in_progress": true
    },
    "logpoint_identifier": "7438xxx",
    "pool_uuid": "ae7dxxx",
    "response": {}
}

3. queued

The request is in the queue and Logpoint has not started processing the request. In this case, the "response" object remains empty, and the "in_progress" field is absent.

Example of request in queue:

{
    "request": {
        "data": {
            "id": "688bxxx"
        },
        "action": "/Incidence/get_alert_context_data"
    },
    "logpoint_identifier": "7438xxx",
    "pool_uuid": "ae7dxxx",
    "response": {}
}

4. failed

The request has finished processing but it was unsuccessful. In this case, the "success" field inside the response is false.

Example of an unsuccessful response:

{
    "request": {},
    "logpoint_identifier": "2ea932a7bxxxxxxxxxxxxxxxxx34",
    "pool_uuid": "4e78450xxxxxxxxxx867a",
    "response": {
        "success": false,
    }
}