Skip to main content

Query the Reporting Data API

To read OpenLM Platform reporting data, send GraphQL queries or CSV export requests to the endpoints on this page. This page lists the endpoints, query parameters, and every GraphQL query the OpenLM Reporting Data API exposes. Authentication is covered in Authenticate to the Reporting Data API. For the fields each query returns, see the Reporting Data API field reference.

All requests require a valid Authorization: Bearer <token> header. The Reporting Data API is a GraphQL API: you read all data through a single GraphQL endpoint, plus a set of REST endpoints for CSV exports.

Endpoints​

The following table lists the endpoints:

EndpointMethodPurpose
{API_BASE_URL}/graphqlPOSTAll data queries (and the in-browser GraphQL explorer on GET).
{API_BASE_URL}/api/reporting/{report}POSTCSV exports of the six main reports.
{API_BASE_URL}/healthGETHealth check.

Schema names are camelCase (licenseUsage, pageInfo, totalCount, orderBy). Report node fields are snake_case (user_name), except the devices query, whose fields are camelCase (deviceName). The groupBy and orderBy argument values are raw column names in snake_case (for example, "feature_name").

Reporting period​

Report queries cover a rolling 90-day period, applied to each report's event-time column:

  • If you don't filter on dates, you get the last 90 days.
  • A requested date range must be 90 days or less. The API refuses a wider range with the GraphQL error code DATE_RANGE_TOO_WIDE.
  • Filter-value lookup queries also cover the last 90 days, so they stay consistent with the report they belong to.
  • projectData, procuredItems, inventoryItems, licenseServerStatus, and the dashboard widget queries are not limited to 90 days. They always return current data.

The column the window applies to, per report:

ReportEvent-time column
licenseUsagestart_time_utc
licenseDenialsdenial_date
sessionDetailssession_start_time
touchpointDetailsevent_date_time
dongleMonitoring, devicesdevice_connected_date_time
utilizationByFeature, utilizationByVendorstart_date_utc
Note

Write date bounds as literal values inside the where argument (or, for the utilization queries, in startDate/endDate). The API can't validate date bounds passed as GraphQL variables. It then applies the default last-90-days window on top of your filter instead of raising an error.

Query parameters​

These parameters apply to the queries on this page:

ParameterTypeWhat it does
firstInt(Cursor paging) How many records to retrieve from the start, for example first: 25.
afterString(Cursor paging) A cursor string from a previous response that retrieves the next page after it.
last / beforeInt / String(Cursor paging) Same idea but paging backwards from the end.
skipInt(Offset paging) How many records to skip before reading.
takeInt(Offset paging) How many records to read after skipping.
searchTermString(Filter lists) Optional text to narrow the values in a drop-down list. Leave empty to get all distinct values.
limitInt(Widgets only) How many rows the widget returns. See notes per query.
where(filter object)Optional filter on any field of the result (autogenerated by the server).
order(sort object)Optional sort on any field of the result (autogenerated by the server).
Note

The available queries depend on the deployment mode. Queries marked (On-premises only) exist only in on-premises deployments. Queries marked (Cloud only) exist only in OpenLM Platform. Everything else is in both.

Main report queries​

These return paged data. Use cursor-paging parameters: first, after, last, before. They also accept where (filter) and order (sort) on any field. A page returns at most 250 records. The following table lists the main report queries:

QueryParametersNotes
licenseUsagefirst, after, last, before, where, orderLicense usage records.
licenseDenialsfirst, after, last, before, where, orderLicense denial records.
sessionDetailsfirst, after, last, before, where, orderApplication/session records.
projectDatafirst, after, last, before, where, orderProject records.
touchpointDetailsfirst, after, last, before, where, orderTouchpoint (web activity) records.
dongleMonitoringfirst, after, last, before, where, orderDongle/device monitoring records.
devicesfirst, after, last, before, where, orderDevice records. Field names are camelCase, unlike the other reports.
utilizationByFeature (Cloud only)featureName: String, startDate: DateTime, endDate: DateTime, plus paging, where, orderConcurrent license utilization. All three arguments are optional: featureName limits the result to a single feature, startDate/endDate limit it to a period.
utilizationByVendor (Cloud only)vendor: String, startDate: DateTime, endDate: DateTime, plus paging, where, orderThe same utilization data, limited to a single vendor.
procuredItems (Cloud only)first, after, last, before, where, orderPurchased licenses, with quantity allocated and available.
inventoryItems (Cloud only)first, after, last, before, where, orderLicense inventory details.

Request, for example, licenseUsage(first: 25). The response includes pageInfo.hasNextPage and an endCursor. Pass that cursor as after to get the next page: licenseUsage(first: 25, after: "<endCursor>"). totalCount gives the full record count.

Count queries (Cloud only)​

These queries return a single number and take no parameters. The following table lists them:

QueryReturnsMeaning
licenseUsageActiveLicenseCountIntCount of active licenses.
licenseUsageHostRunningCountIntCount of running hosts.
licenseDenialsDenialCountInLast24HoursIntDenials in the last 24 hours.
licenseDenialsNewAlertsCountIn24HoursIntDistinct new denial alerts in the last 24 hours.

To use a count query, call it directly, for example { licenseUsageActiveLicenseCount }.

Filter-value lookup queries​

These return a paged list of distinct, sorted values for a single field, for building filter drop-down lists. Every query takes an optional searchTerm plus the offset-paging parameters skip (Int) and take (Int). Each of the following tables lists the searchTerm type for that query.

The following table lists the License Usage queries:

QuerysearchTerm
licenseUsageLicenseTypeFilterValuesString
licenseUsageVersionFilterValuesString
licenseUsageUserNameFilterValuesString
licenseUsageWorkstationFilterValuesString
licenseUsageVendorFilterValuesString
licenseUsageFeaturePackageFilterValuesString
licenseUsageFeatureProductFilterValuesString
licenseUsageFeaturePackageItemFilterValuesString
licenseUsageIsTokenBasedFilterValuesString

The following table lists the License Denials queries:

QuerysearchTerm
licenseDenialsUserNameFilterValuesString
licenseDenialsWorkstationFilterValuesString
licenseDenialsMinorErrorFilterValuesString
licenseDenialsMajorErrorFilterValuesString
licenseDenialsErrorTextFilterValuesString
licenseDenialsFeatureNameFilterValuesString
licenseDenialsStatusFilterValuesString
licenseDenialsGroupIdFilterValues (Cloud only)String
licenseDenialsGroupNameFilterValues (Cloud only)String
licenseDenialsCategoryFilterValuesString
licenseDenialsVendorFilterValuesString
licenseDenialsFeatureVersionFilterValues (Cloud only)String
licenseDenialsLicenseTypeFilterValuesString
licenseDenialsAdditionalKeyFilterValuesString
licenseDenialsHostnameFilterValuesString
licenseDenialsLicenseServerFilterValues (Cloud only)String

The following table lists the Session Details queries:

QuerysearchTerm
sessionDetailsUserFilterValuesString
sessionDetailsWorkstationFilterValuesString
sessionDetailsIdleTimeFilterValuesFloat
sessionDetailsSessionEndTimeHolidaysFilterValuesDateTime
sessionDetailsSessionEndTimeWeekdaysFilterValuesDateTime
sessionDetailsSessionFilterValuesFloat
sessionDetailsProcessFilterValuesString
sessionDetailsDependencyFilterValuesString
sessionDetailsCustomerFilterValuesString
sessionDetailsReasonFilterValuesString
sessionDetailsAgentStatusFilterValuesInt
sessionDetailsVersionFilterValuesString

The following table lists the Touchpoint Details queries:

QuerysearchTerm
touchpointDetailsUsernameFilterValuesString
touchpointDetailsWorkstationFilterValuesString
touchpointDetailsEventDateTimeFilterValuesDateTime

The following table lists the Dongle Monitoring queries:

QuerysearchTerm
dongleMonitoringDeviceNameFilterValuesString
dongleMonitoringDeviceDescriptionFilterValuesString
dongleMonitoringManufacturerFilterValuesString
dongleMonitoringUserNameFilterValuesString
dongleMonitoringHostNameFilterValuesString
dongleMonitoringBlacklistedFilterValuesString
dongleMonitoringAgentStatusFilterValuesInt

The following table lists the Project Data queries:

QuerysearchTerm
projectDataProjectNameFilterValuesString
projectDataUserNameFilterValuesString
projectDataPriorityFilterValuesString
projectDataSourceFilterValuesString
projectDataGroupNameFilterValues (On-premises only)String

The following table lists the device filter queries:

QuerysearchTermNotes
deviceNameFilterValuesStringNone
deviceManufacturersFilterValuesStringNone
deviceHostNameFilterValuesStringAccepts an optional deviceId (String) to restrict results to a single device.
deviceUserNameFilterValuesStringAccepts an optional deviceId (String) to restrict results to a single device.

For example, licenseUsageVendorFilterValues(searchTerm: "auto", take: 20) returns up to 20 distinct vendors containing "auto". Omit searchTerm to list all values.

Dashboard widget queries (Cloud only)​

These return a simple list (not paged). The key parameter is limit.

The limit parameter works as follows:

  • Top-N widgets: limit accepts only 5 or 10. Any other value (or omitting it) defaults to 10. So limit: 5 returns 5 rows, and any other value returns 10 rows.
  • Full-list widgets (activeUsersReport, licenseServerStatus, and hostAvailability): limit accepts 1 to 100. Out-of-range or omitted values default to 100 (a safety cap).

The following table lists the widget queries:

QueryParameterNotes (what it returns / ordering)
topDeniedFeatureslimit: Int (5/10)Most-denied features, highest first.
topDeniedUserslimit: Int (5/10)Users with the most denials, highest first.
topMostUsedFeatureslimit: Int (5/10)Most-used features, highest usage first.
topLeastUsedFeatureslimit: Int (5/10)Least-used features, lowest usage first.
topLongestSessionslimit: Int (5/10)Longest sessions, longest first.
topIdleSessionslimit: Int (5/10)Most idle sessions, highest idle time first.
topProductNameslimit: Int (5/10)Top products by usage.
topVendorNameslimit: Int (5/10)Top vendors by usage.
topMostActiveUserslimit: Int (5/10)Most-active users (only users with at least 1 session).
topLeastActiveUserslimit: Int (5/10)Least-active users (only users with at least 1 session).
activeUsersReportlimit: Int (1 to 100, default 100)Active sessions.
licenseServerStatuslimit: Int (1 to 100, default 100)License server status list.
hostAvailabilitylimit: Int (1 to 100, default 100)Host availability list.

For example, topDeniedFeatures(limit: 5) returns the top 5. activeUsersReport(limit: 50) returns up to 50 active sessions.

CSV exports​

You can download six reports as CSV files. Send a POST to {API_BASE_URL}/api/reporting/{report}, with {report} set to any of:

  • GetLicenseUsageCSV
  • GetLicenseDenialsCSV
  • GetSessionDetailsCSV
  • GetTouchpointDetailsCSV
  • GetDongleMonitoringCSV
  • GetProjectDataCSV

The request body has three parts:

  • filterColumns: the columns you want in the file, in order. Use the same field names as the matching report in the Reporting Data API field reference.
  • filterOptions: which records to include.
    • startDateTime and endDateTime set the period. Each takes an interval object with optional startIntervalDateTime and endIntervalDateTime bounds, as in the example.
    • Each selected... list narrows the results to those values. Omit a list to include everything.
  • userConfigurations: the value formatting for the file: timezone, dateFormat, decimalSymbol, thousandsSeparator.
    • timezone takes an IANA time zone ID, such as Europe/Berlin or America/New_York. OpenLM converts the times in the file from UTC to that zone. Leave it empty for UTC. An unrecognized ID fails the request.
    • dateFormat must be one of the six UI Configurations date formats: dd/MM/yyyy hh:mm:ss, MM/dd/yyyy hh:mm:ss, yyyy-MM-dd hh:mm:ss, dd/MM/yyyy HH:mm:ss, MM/dd/yyyy HH:mm:ss, or yyyy-MM-dd HH:mm:ss. Leave it empty for yyyy-MM-dd HH:mm:ss. Any other value fails the request. The hh formats use a 12-hour clock without AM or PM, so use an HH format unless you add the period yourself.

The selected... lists each report accepts:

Reportselected... lists
GetLicenseUsageCSVselectedLicInvVendor, selectedLicInvType, selectedLicInvVersion, selectedUserName, selectedHostName, selectedProductName, selectedIsTokenBased
GetLicenseDenialsCSVselectedUserName, selectedWorkstation, selectedMinorErr, selectedMajorErr, selectedErrorMessage, selectedFeatureName, selectedStatus, selectedGrpId, selectedGrpName, selectedCategory, selectedVendor, selectedVersion, selectedLicenseType, selectedAdditionalKey, selectedHostName, selectedLicsrvDescription
GetSessionDetailsCSVselectedUserNames, selectedHostNames, selectedProcessNames, selectedDllNames, selectedShutdownReasons, selectedVersion, selectedAgentStatuses
GetTouchpointDetailsCSVselectedUserNames, selectedWorkstations
GetDongleMonitoringCSVselectedDeviceName, selectedDeviceDescription, selectedManufacturer, selectedUserName, selectedHostName, selectedAgentStatus
GetProjectDataCSVselectedProjectName, selectedUserName, selectedPriority, selectedSource, selectedGroupName

The response is the CSV file itself.

Example​

This request exports license usage records to license_usage.csv:

curl -X POST "{API_BASE_URL}/api/reporting/GetLicenseUsageCSV" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"filterColumns": ["user_name", "feature_name", "vendor", "start_time_utc"],
"filterOptions": {
"startDateTime": { "startIntervalDateTime": "2026-06-01T00:00:00Z" },
"endDateTime": { "endIntervalDateTime": "2026-08-01T00:00:00Z" },
"selectedUserName": [],
"selectedProductName": []
},
"userConfigurations": {
"timezone": "UTC",
"dateFormat": "dd/MM/yyyy HH:mm:ss",
"decimalSymbol": ".",
"thousandsSeparator": ","
}
}' \
--output license_usage.csv

For more information, see these pages:

The documentation team might draft this page using a large language model. A technical writer reviews every page and verifies it against the product before publishing it. A human makes the final decision.