Client telemetry
DCT provides complete flexibility to clients on how to attribute their API calls. DCT captures the value provided in an optional HTTP header (X-Dct-Client-Name
) and standard, mandatory HTTP header (User-Agent
) for the purpose of attributing an API call. These values are stored as client_name
and user_agent
in the backend, and can be queried in the report. Below are some examples of how this can be used.
Example one
Clients can view the report grouped on the basis of client name and API classification by providing a group_by
query parameter.
curl --location 'https://[Inser_DCT_Server]/v3/reporting/api-usage-report?group_by=client_name%2Ckind' \
--header 'Authorization: <api_key>' \
--header 'Accept: text/csv'
api_endpoint,api_method,api_count,kind,client_name,user_agent,dct_version
,,2,management,client-1,,
,,5,management,client-2,,
,,20,management,client-3,,
The group_by
parameter supports any combination of properties from api_endpoint
, api_method
, kind
, client_name
, user_agent
, and dct_version
. All properties function as their name describes, where kind
corresponds to API classification.
Example two
Clients filter the records for a list of particular client names, DCT versions, user agents, or classifications, by providing corresponding query parameters.
Filter the API calls by client names.
NONEcurl --location 'https://[Inser_DCT_Server]/v3/reporting/api-usage-report?group_by=client_name%2Ckind&client_name=client1%2Cclient2' \ --header 'Authorization: <api_key>' \ --header 'Authorization: apk <api key>
Filter the API calls by API classification.
NONEcurl --location 'https://[Inser_DCT_Server]/v3/reporting/api-usage-report?group_by=client_name%2Ckind&api_metric_kind=automation' \ --header 'Authorization: <api_key>' \ --header 'Authorization: apk <api key>'
The API query parameters for this report are dynamic; depending on the number of records in the backend and the granularity of the response requested, API response can be too large to be handled by DCT. DCT can run out of memory and eventually crash if that is the case. To prevent this from happening, this report has the maximum limit set to 10,000 records in the API response. Thus, it is strongly recommended to always ‘limit’ the scope of the usage response by filtering records on the basis of start_date
and end_date
query parameters, or on the basis of client names and/or user agents.