• Applies to: Sprinklr Reporting API, version 3 (/api/v3/reports/*), OpenAPI tag Reporting V3
• V2 API reference: Reporting (index) — Custom Query, Custom Query Using Widget Id, Batch Query, Fetch Reporting Engines, Fetch Report Names, Fetch Custom Metrics, Fetch Metrics and Dimensions

The Reporting API returns the same analytics data that Sprinklr's reporting dashboards display. The OpenAPI document describes the Reporting V3 tag as:

Run analytics queries and retrieve reporting metadata. Supports single, widget, and batch queries, listing reporting engines and enabled report names, fetching report metadata and custom measurements, retrieving viral trend insights, returning compiled backend query strings, and Research Assistant queries.

Reporting is a four-level hierarchy. You must resolve each level before you can query.

The intended path to a working payload is not to hand-write one. Build the widget in the UI, then export its payload:

1. Create a dashboard and add a widget that shows the data you want.
2. Grant your user the Generate Widget API Payload role permission — Governance Console → All Settings → Workspace Roles (or Global Roles) → Create/Edit Role.
3. On the widget, open the three-dot menu → Generate API v2 Payload.
4. Choose Copy Code and paste the result into your request body.

Two constraints from the Blueprints article that surprise people:

• "a separate API payload needs to be generated for every widget within the dashboard."
• "dashboard level filters will not be reflected in the payload that is generated." — fold any dashboard-level filter into the widget, or add it manually to filters.

To use the exported payload with POST /reports/query/widget, find widgetId inside the additional object of the generated payload.

• A registered Developer Portal application with an API key and secret. Best practice from the Blueprints article: register the app against a service account, not a personal user account, so the integration survives staff changes.
• An OAuth 2.0 access token. Validate it against the "ME" endpoint before debugging anything reporting-specific.
• Reporting view permission for the dashboards and workspaces you intend to query. A token whose user lacks workspace (client) access is the most common cause of a successful-but-empty response.
• The Generate Widget API Payload permission if you intend to export payloads from the UI.

• Base URL is written {base} and stands for `https://{host}/{env}.
• Credentials always appear as {{accessToken}} and {{apiKey}}. Never paste a real token into a shared document or ticket.
• All epoch timestamps are milliseconds.

{base} = https://{host}/{env}

Full request path:

{base}/api/v3/reports/{operation}

All seven endpoints use the same headers. The V2 pages document four:

Header casing note: HTTP header names are case-insensitive, so Key and key are equivalent.

The four GET endpoints resolve the hierarchy described in §1.1. Call them in the order below the first time you integrate; cache the results afterwards, since engine and report catalogues change rarely.

Summary. List reporting engines visible to the current partner. operationId. ReportingApiV3_listReportingEngines Response. 200 with the standard APIResponse envelope.

This is the entry point. The id values it returns are what you pass as reportingEngine in a query body and as reportingEngineId to the other three discovery endpoints.

None. The result is scoped implicitly to the partner and user behind the access token.

curl -X GET \
  'https://api3.sprinklr.com/{env}/api/v3/reports/engine' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Accept: application/json'

{
  "data": [
    { "id": "PLATFORM", "name": "Social Analytics" },
    { "id": "INBOUND_MESSAGE", "name": "Inbound Analytics" },
    { "id": "LISTENING", "name": "Listening" }
  ],
  "errors": []
}

The following 38 engines were returned by the V2 endpoint. The set visible to your token depends on your partner's licensed products, so always call the endpoint rather than hard-coding this list.

Three things to note before you build a UI on top of this list:

• name is not unique. Benchmarking, Listening Explorer, Self Serve and Story Analytics each appear twice under different ids. Key your code on id, and if you present a picker, disambiguate the duplicates yourself.
• id casing is not uniform. wfm_reporting is lower-case while every other id is upper snake case. Do not normalise case when echoing an id back to the API.
• Some entries expose an internal identifier as the display name — AUDIENCE_LEAD, LYEARN_REPORTING_ENGINE, VOICE_SEGMENT_ACTIVATION_CONFIG. These are unlikely to be presentable to end users as-is.

Summary. List the reports enabled for a reporting engine. Response. 200 with the standard APIResponse envelope.

Given an engine id from, this returns the reports available within it. The values feed the report field of a query body and the reportNames parameter.

curl -X GET \
  'https://api3.sprinklr.com/{env}/api/v3/reports/report?reportingEngineId=PLATFORM' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Accept: application/json'

The response is an array of {id, name} objects, one per report. The PLATFORM engine returns several hundred; this is an abridged extract.

{
  "data": [
    { "id": "ACCOUNT_INBOUND_VOLUME", "name": "ACCOUNT_INBOUND_VOLUME" },
    { "id": "ACCOUNT_INSIGHTS", "name": "ACCOUNT_INSIGHTS" },
    { "id": "AGENT_PERFORMANCE_AGGREGATED_REPORT", "name": "AGENT_PERFORMANCE_AGGREGATED_REPORT" },
    { "id": "ANALYTICS", "name": "ANALYTICS" },
    { "id": "FACEBOOK_HOURLY_INSIGHTS", "name": "FACEBOOK_HOURLY_INSIGHTS" },
    { "id": "POST_INSIGHTS", "name": "POST_INSIGHTS" },
    { "id": "CaseSLAReport", "name": "CaseSLAReport" }
  ],
  "errors": []
}

Note that report ids are not uniformly upper snake case — the V2 response mixes ACCOUNT_INSIGHTS with CaseSLAReport, CaseProcessingSLAReport and ComprehensiveCaseSLAReport. Treat report ids as opaque, case-sensitive strings.

Summary. Get report metadata for a reporting engine. operationId. ReportingApiV3_getMetadata Response. 200 with the standard APIResponse envelope.

This is the endpoint that tells you what you are allowed to put in projections and groupBys. For each requested report it returns the full catalogue of measurements (metrics), dimensions, and filter dimensions, with their field names, data types and display names.

curl -X GET \
  'https://api3.sprinklr.com/{env}/api/v3/reports/metadata?reportingEngineId=PLATFORM&reportNames=POST_INSIGHTS' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Accept: application/json'

To request several reports, comma-separate them:

?reportingEngineId=PLATFORM&reportNames=POST_INSIGHTS,ACCOUNT_INSIGHTS

Heavily abridged — a real response for one report is several hundred lines.

{
  "data": {
    "POST_INSIGHTS": {
      "recordType": "LIFETIME",
      "displayName": "POST_INSIGHTS",
      "dateFieldName": "date",
      "skipVisibilityFilters": false,
      "measurements": [
        {
          "type": "CUMULATIVE",
          "measurementGroups": ["FACEBOOK"],
          "name": "POST_FB_NEGATIVE_FEEDBACK_BY_TYPE_UNIQUE_HIDE_ALL_CLICKS",
          "fieldName": "POST_FB_NEGATIVE_FEEDBACK_BY_TYPE_UNIQUE_HIDE_ALL_CLICKS",
          "displayName": "Facebook Post Negative Feedback Unique All Hide",
          "isShared": false,
          "filterMeasurement": true,
          "hidden": false,
          "enabledForAiConcierge": false,
          "channelTypes": ["FACEBOOK"]
        }
      ],
      "dimensions": [
        {
          "type": "SCRIPT",
          "name": "postFeatures.ocr_gcv",
          "fieldName": "postFeatures.ocr_gcv",
          "displayName": "Creative Insight: All Text in Asset",
          "filterDimension": true,
          "multiValue": true,
          "sortable": false,
          "lookupSupported": true,
          "hidden": false
        }
      ],
      "oldCustomFieldDimensionName": "OUTBOUND_CUSTOM_PROPERTY_NAME"
    }
  },
  "errors": []
}

Commonly useful fields on each measurement and dimension object:

When a response contains a custom property field name you do not recognise, copy that field name from the request and pass it to the fetch custom field using field name API to retrieve the label shown in the UI.

Summary. Get custom measurements for a reporting engine. operationId. ReportingApiV3_getCustomMetrics Response. 200 with the standard APIResponse envelope.

Custom measurements are metrics your organisation has defined itself in Sprinklr — typically a formula over one or more standard measurements. §6 returns the standard catalogue; this endpoint returns the customer-defined additions, together with the formula behind each.

curl -X GET \
  'https://api3.sprinklr.com/{env}/api/v3/reports/custom-metric?reportingEngineId=PLATFORM&reportNames=ACCOUNT_INSIGHTS' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Accept: application/json'

{
  "data": {
    "ACCOUNT_INSIGHTS": [
      {
        "script": " (__formula__elem__453*1000)",
        "requiredProjections": [
          {
            "key": "__formula__elem__453",
            "measurement": "FOLLOWERS_COUNT",
            "aggregateFunction": "SUM"
          }
        ],
        "measurementGroups": ["COMMON"],
        "groupNames": ["Custom Measurement"],
        "isShared": false,
        "sharedKey": "EXAMPLE_METRIC_1",
        "filterMeasurement": true,
        "name": "EXAMPLE_METRIC_1",
        "fieldName": "EXAMPLE_METRIC_1",
        "displayName": "Followers per thousand",
        "lcName": "followers per thousand",
        "hidden": false,
        "enabledForAiConcierge": false,
        "dataType": "NUMERIC",
        "additional": {
          "measurement_type": "Custom Measurement",
          "clientId": 0000,
          "IS_PERMISSIBLE": "false",
          "definitionId": "000000000000000000000000"
        }
      },
      {
        "script": " (__formula__elem__1001+__formula__elem__1002)",
        "requiredProjections": [
          {
            "key": "__formula__elem__1001",
            "measurement": "FOLLOWERS_COUNT",
            "aggregateFunction": "SUM"
          },
          {
            "key": "__formula__elem__1002",
            "measurement": "FACEBOOK_PAGE_FANS",
            "aggregateFunction": "SUM"
          }
        ],
        "type": "CALCULATED",
        "measurementGroups": ["COMMON"],
        "groupNames": ["Custom Measurement"],
        "isShared": false,
        "sharedKey": "EXAMPLE_METRIC_2",
        "filterMeasurement": true,
        "name": "EXAMPLE_METRIC_2",
        "fieldName": "EXAMPLE_METRIC_2",
        "displayName": "Total audience",
        "lcName": "total audience",
        "filters": [],
        "hidden": false,
        "enabledForAiConcierge": false,
        "dataType": "NUMERIC",
        "additional": {
          "definitionId": "000000000000000000000001",
          "measurement_type": "Custom Measurement",
          "IS_PERMISSIBLE": "false",
          "clientId": 0000
        }
      }
    ]
  },
  "errors": []
}

The metric names, display names, sharedKey, definitionId and clientId values above are illustrative placeholders and do not identify a real customer configuration.

To use a custom metric in a query, put its fieldName in projections[].measurementName exactly as returned — Sprinklr resolves the formula server-side. You do not need to reproduce script or requiredProjections yourself.

Summary. Execute a reporting query (plain ReportRequest). operationId. ReportingApiV3_query Request body. ReportRequest, required. Response. 200 with the standard APIResponse envelope.

The general-purpose endpoint. You specify the engine, the report, the time range, and the dimensions, metrics, filters and sorts explicitly.

No path or query parameters. Everything is in the body — see §11.1.

curl -X POST \
  'https://api3.sprinklr.com/{env}/api/v3/reports/query' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{
    "reportingEngine": "PLATFORM",
    "report": "ACCOUNT_INSIGHTS",
    "startTime": 1735689600000,
    "endTime": 1738368000000,
    "timeZone": "America/New_York",
    "page": 0,
    "pageSize": 100,
    "groupBys": [
      {
        "heading": "Channel",
        "dimensionName": "SOCIAL_NETWORK",
        "groupType": "FIELD"
      }
    ],
    "projections": [
      {
        "heading": "Followers",
        "measurementName": "FOLLOWERS_COUNT",
        "aggregateFunction": "SUM"
      }
    ],
    "filters": [
      {
        "dimensionName": "ACCOUNT_ID",
        "filterType": "IN",
        "values": ["000000000000000000000000"]
      }
    ],
    "sorts": [
      {
        "heading": "Followers",
        "order": "DESC"
      }
    ],
    "jsonResponse": true
  }'

With jsonResponse set to true, rows are returned as objects keyed by heading:

{
  "data": {
    "data": [
      {
        "Channel": "FACEBOOK",
        "Followers": 128394
      },
      {
        "Channel": "TWITTER",
        "Followers": 94021
      }
    ],
    "hasMore": false
  },
  "errors": []
}

With jsonResponse set to false, the same result arrives in the compact columnar form — see §12.2.

Summary. Execute a reporting query for a dashboard widget. operationId. ReportingApiV3_queryWidget Request body. WidgetReportRequest, required. Response. 200 with the standard APIResponse envelope.

The widget already defines the report, engine, dimensions, metrics and filters, so the body carries only the time range, paging and formatting options. This is the lowest-effort way to pull dashboard data programmatically.

1. Open the dashboard containing the widget.
2. Widget three-dot menu → Generate API v2 Payload → Copy Code.
3. In the copied payload, locate widgetId inside the additional object.

WidgetReportRequest defines only eight fields.

curl -X POST \
  'https://api3.sprinklr.com/{env}/api/v3/reports/query/widget?widgetId=000000000000000000000000' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{
    "startTime": 1735689600000,
    "endTime": 1738368000000,
    "timeZone": "America/New_York",
    "page": 0,
    "pageSize": 1000,
    "skipResolve": false,
    "jsonResponse": false
  }'

With jsonResponse set to false, the widget endpoint returns the columnar form:

{
  "data": {
    "headings": ["Channel", "Followers"],
    "rows": [
      ["FACEBOOK", 128394],
      ["TWITTER", 94021]
    ]
  },
  "errors": []
}

Summary. Execute multiple reporting queries in one request. operationId. ReportingApiV3_batchQuery Request body. BatchReportRequest, required. Response. 200 with the standard APIResponse envelope.

Use this when you need several results in one round trip, or when a single widget draws its metrics and dimensions from more than one report type. From the V2 page:

If the configured metrics and dimensions in a widget are being pulled from multiple report types, batch query API is used.

curl -X POST \
  'https://api3.sprinklr.com/{env}/api/v3/reports/batchQuery' \
  -H 'Authorization: Bearer {{accessToken}}' \
  -H 'Key: {{apiKey}}' \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json' \
  -d '{
    "requests": {
      "req1": {
        "reportingEngine": "PLATFORM",
        "report": "ACCOUNT_INSIGHTS",
        "startTime": 1735689600000,
        "endTime": 1738368000000,
        "timeZone": "America/New_York",
        "page": 0,
        "pageSize": 100,
        "groupBys": [
          { "heading": "Channel", "dimensionName": "SOCIAL_NETWORK", "groupType": "FIELD" }
        ],
        "projections": [
          { "heading": "Followers", "measurementName": "FOLLOWERS_COUNT", "aggregateFunction": "SUM" }
        ],
        "filters": []
      },
      "req2": {
        "reportingEngine": "INBOUND_MESSAGE",
        "report": "INBOUND_CASE",
        "startTime": 1735689600000,
        "endTime": 1738368000000,
        "timeZone": "America/New_York",
        "page": 0,
        "pageSize": 100,
        "groupBys": [
          { "heading": "Channel", "dimensionName": "SOCIAL_NETWORK", "groupType": "FIELD" }
        ],
        "projections": [
          { "heading": "Volume", "measurementName": "INBOUND_COUNT", "aggregateFunction": "SUM" }
        ],
        "filters": []
      }
    },
    "collate": false
  }'

Results are returned in a reports map keyed by the same keys you sent.

{
  "data": {
    "reports": {
      "req1": {
        "headings": ["Channel", "Followers"],
        "rows": [
          ["FACEBOOK", 128394],
          ["TWITTER", 94021]
        ]
      },
      "req2": {
        "headings": ["Channel", "Volume"],
        "rows": [
          ["FACEBOOK", 4821],
          ["TWITTER", 3107]
        ]
      }
    }
  },
  "errors": []
}

The V2 page documents these sub-fields of additional on a batch sub-request. They are typically populated automatically by the UI payload generator.

Note that sorting is keyed on heading, not on dimensionName or measurementName — so headings must be unique within a request if you intend to sort.

Batch sub-requests carry additional key.

All five fields are plain type: string in V3. The values below are taken from the V2 documentation and are the only published list.

filterType — used in filters[] and projectionFilters[]:

groupType — used in groupBys[]:

aggregateFunction — used in projections[]:

order — used in sorts[]: ASC, DESC.

projectionDecorations — derived columns added alongside a projection:

All seven endpoints return the standard APIResponse envelope:

jsonResponse changes the structure of the result, not merely its formatting. This trips up almost everyone migrating.

Four distinct response shapes appear across the seven endpoints:

Every one of the seven operations declares exactly these five: