CFM Survey Response APIs V3 — Developer Guide

• Applies to: Sprinklr Customer Feedback Management (CFM) Survey Response APIs V3 (/api/v3/surveyResponse)
• V2 API reference: CFM Survey Response APIs | Sprinklr Developer Portal · Fetch Survey Response (V2)

A survey response is a single completed submission against a Sprinklr CFM survey. It records what the respondent answered, who they were, how and when they answered, and any custom metadata attached to the response, the responder's profile, or the transaction that triggered the survey.

The CFM Survey Response APIs let you move response data programmatically in both directions. Per the Sprinklr Help Center: "You can leverage the Standard CRUD APIs for survey responses to programmatically create, retrieve, update, or delete response data within the Sprinklr system. This capability facilitates seamless integration with external systems and supports automated workflows."

Five operations are exposed across two paths — four methods on /api/v3/surveyResponse, plus a dedicated search path:

This single-path, method-differentiated shape is the central design change in V3, and it matches the pattern already used by Profile V3 (/api/v3/profile) and Survey Transactions V3 (/api/v3/surveyTransactions). V2 spread the same capabilities across separately-named paths such as /api/v2/survey-response/{survey-response-id}.

Response data is modeled in three layers. Understanding this model is the fastest way to understand every endpoint in this guide.

The three custom-metadata namespaces are the part most developers get wrong:

A response is addressed by its responseId — for example 6a8c451269baf80612fb6417 — passed as the id query parameter.

sprinklr-v3.yaml describes id on GET and DELETE as a "Comma-separated list of survey response ids", so both operations are bulk-capable. On PUT the description is singular: "Survey response id."

To find a responseId in the Sprinklr UI:

1. Open the Customer Feedback Management (CFM) persona app in Sprinklr.
2. In the Programs tab, locate the survey whose responses you want.
3. Hover over the survey. A View button is displayed. Click View.
4. On the top bar, click Responses.
5. The Response Id column values are the responseId.

To find a custom field's internal name:

1. Open the CFM persona app and navigate to the Programs tab.
2. Hover over the survey and click View.
3. From the top navigation bar, click Settings.
4. Scroll to Survey Custom Fields. It contains Transaction Fields and Response Custom Fields.
5. Click View Fields next to the category you need.
6. Find the field, click the three-dot menu (⋮), and select Copy Field Name to copy the internal field ID used in API requests.

Internal field names follow the pattern _c_<24-hex-id>, for example _c_67cb50793cae6f06c0c41de0.

1. CFM must be enabled in your environment. Per the Developer Portal: "CFM must be enabled in your environment before you can utilize these APIs. Please contact your Success Manager for more details."
2. Permissions. Per the Help Center: "You would need View and Edit Response and Analytics permissions at the Survey Level." The API user must be able to access the survey's analytics in the UI.
3. You must know the surveyId for the survey you are integrating with, and the specific responseId values for read, update, and delete operations.
4. Request a sample payload from Sprinklr Support. All five supplied endpoint specifications carry the same Dev Note: "To use this API, you will need values for the parameters mentioned below. To obtain these values, reach out to Sprinklr Support at tickets@sprinklr.com."

All API calls are sent to the production endpoint:

https://api3.sprinklr.com/{env}/api/v3

So the survey response resource in production is:

https://api3.sprinklr.com/{env}/api/v3/surveyResponse

Replace {env} with your assigned environment identifier (prod0, prod2, prod3, prod4, prod5, prod6, prod8, prod11, prod12, prod15–prod19, prod21, prod24, production, spr-uat, azrqa — see APIs | Sprinklr Developer Portal for the authoritative list).

All CFM Survey Response API calls are authenticated with OAuth 2.0. See API Overview for portal registration, API key and secret generation, and the Authorize flow.

Imports a survey response from any external source — a CRM, an internal application, or an offline data-collection tool — into Sprinklr CFM.

POST /api/v3/surveyResponse

Request schema: SurveyResponseIngestionRequest — "Survey Response Ingestion Request"

sprinklr-v3.yaml declares no required array on SurveyResponseIngestionRequest, so no field is formally mandatory. In practice surveyId and questionResponses are the minimum meaningful payload.

curl --location 'https://api3.sprinklr.com/{env}/api/v3/surveyResponse' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "surveyId": "6a840fb9a64a419291aacd53",
    "questionResponses": {
      "422131e5-67e9-4e7d-8edf-448c7e455f0e": ["Neutral"]
    },
    "responseTime": 1738281600000,
    "tags": ["tag1"],
    "distributionChannel": "EXTERNAL_APPLICATION",
    "responseCustomFields": {
      "_c_67cb50793cae6f06c0c41de0": ["5"]
    },
    "profileCustomFields": {
      "_c_64cbf526fd8b0e259d72470a": ["20"]
    },
    "transactionCustomFields": {
      "_c_67056c1056182e36198d8eea": ["WHATSAPP"]
    },
    "responderSnId": null,
    "responderSnType": null,
    "surveyLanguage": null,
    "elapsedTime": null
  }'

{
  "data": {
    "responseId": "6a8c451269baf80612fb6417"
  },
  "errors": []
}

Persist data.responseId — it is the only handle for later fetch, update, or delete.

Retrieves detailed information about a specific survey response using its unique ID.

GET /api/v3/surveyResponse?id={responseId}

Response schema (per sprinklr-v3.yaml): array of SurveyResponseDTO

curl --location 'https://api3.sprinklr.com/{env}/api/v3/surveyResponse?id=6a8c451269baf80612fb6417' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Accept: application/json'

{
  "data": [
    {
      "hasMore": false,
      "responses": [
        {
          "surveyId": "6a840fb9a64a419291aacd53",
          "responseId": "6a8c451269baf80612fb6417",
          "responseStatus": "COMPLETE_RESPONSES",
          "createdTime": 1738281600000,
          "surveyMode": "STANDARD",
          "surveyResponseType": "STANDARD",
          "responderSnId": "6a8c451269baf80612fb6416",
          "responderSnType": "EXTERNAL_APPLICATION",
          "responseQuality": "NA",
          "questionResponses": {
            "422131e5-67e9-4e7d-8edf-448c7e455f0e": ["Neutral"]
          },
          "customProperties": {},
          "profileCustomProperties": {},
          "transactionCustomProperties": {}
        }
      ],
      "metadata": {
        "customFieldLookup": {},
        "questionLookup": {
          "422131e5-67e9-4e7d-8edf-448c7e455f0e": "Question"
        }
      }
    }
  ],
  "errors": []
}

The metadata object is what makes a response payload human-readable: it maps opaque identifiers back to display names.

Searches survey responses for a specific survey, with pagination and filtering.

POST /api/v3/surveyResponse/search?surveyId={surveyId}

*** SurveyResponseFetchRequest — "Survey Response Fetch Request"

Per the Help Center, this operation exists to "Obtain a list of survey responses that fulfill particular filtering criteria, including survey custom properties or responder characteristics… Collect survey responses in large quantities according to specific criteria for the purpose of reporting or integration."

Two incompatible request-body shapes are documented. Both are reproduced here because neither can be dismissed from the available evidence.

Values in the supplied table listed as filter types but which are in fact properties of a filter, not types:

V2 documents SURVEY_CUSTOM_PROPERTY as a field value, paired with details.fieldName carrying the internal custom-field ID.

curl --location 'https://api3.sprinklr.com/{env}/api/v3/surveyResponse/search?surveyId=6a840fb9a64a419291aacd53' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "page": 0,
    "pageSize": 20
  }'

curl --location 'https://api3.sprinklr.com/{env}/api/v3/surveyResponse/search?surveyId=6a840fb9a64a419291aacd53' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "page": {
      "start": 0,
      "size": 20
    },
    "filters": [
      {
        "field": "SURVEY_CUSTOM_PROPERTY",
        "filterType": "IN",
        "values": ["Promoter"],
        "details": {
          "fieldName": "_c_67ce77b1ddff1d4b9bc831ce"
        }
      }
    ]
  }'

{
  "data": {
    "hasMore": false
  },
  "errors": []
}

Updates the custom fields on an existing survey response. Per the Help Center, use it to "Change particular areas in a survey response, including the modification of tags, custom fields, or metadata… Improve or enhance current replies by adding missing information or making corrections. Utilize this API for performing bulk updates through scripts."

PUT /api/v3/surveyResponse?id={responseId}

Request schema: SurveyResponseUpdateV3Request — "Request body for updating CFM survey response custom fields via API v3."

Only custom fields can be updated. Answers (questionResponses), responseStatus, tags, and every system field are not writable through this endpoint. Despite the method being PUT, the operation summary in sprinklr-v3.yaml is "Update survey response custom fields by id" — it is scoped to the three custom-field namespaces only.

curl --location --request PUT 'https://api3.sprinklr.com/{env}/api/v3/surveyResponse?id=6a8c451269baf80612fb6417' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "responseCustomFields": {
      "_c_67cb50793cae6f06c0c41de0": ["5"]
    },
    "profileCustomFields": {
      "_c_64cbf526fd8b0e259d72470a": ["20"]
    },
    "transactionCustomFields": {
      "_c_67056c1056182e36198d8eea": ["WHATSAPP"]
    }
  }'

The sources disagree.

Permanently deletes a survey response using its unique ID. Per the Help Center, use it to "Remove any duplicate, test, or incorrect entries from the system."

DELETE /api/v3/surveyResponse?id={responseId}

curl --location --request DELETE 'https://api3.sprinklr.com/{env}/api/v3/surveyResponse?id=6a8c451269baf80612fb6417' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Accept: application/json'

Declared in sprinklr-v3.yaml for all five operations:

Per the Help Center's testing guidance, a successful ingestion should return 200 OK and the response should then be visible in the Sprinklr UI under the Survey Responses tab.

This is the change most likely to break a V2 client silently.

V2 routinely carried business identifiers in headers. V3 moves every one of them into the URL or the body. A client that keeps setting the V2 headers will send them harmlessly but will address no resource, producing 400 or 404.

Ingest — the customFields wrapper is removed.

V2:

{
  "questionResponses": { "questionID": ["Free-text answer"] },
  "responseTime": "2025-03-06 15:00:00",
  "customFields": {
    "responseCustomFields": { "_c_67cb50793cae6f06c0c41de0": ["5"] },
    "transactionCustomFields": { "_c_67056c1056182e36198d8eea": ["WHATSAPP"] },
    "profileCustomFields": { "_c_64cbf526fd8b0e259d72470a": ["20"] }
  }
}

V3 — the three objects move to the top level, and surveyId joins them:

{
  "surveyId": "6a840fb9a64a419291aacd53",
  "questionResponses": { "questionID": ["Free-text answer"] },
  "responseTime": 1738281600000,
  "responseCustomFields": { "_c_67cb50793cae6f06c0c41de0": ["5"] },
  "transactionCustomFields": { "_c_67056c1056182e36198d8eea": ["WHATSAPP"] },
  "profileCustomFields": { "_c_64cbf526fd8b0e259d72470a": ["20"] }
}

The enum values below are documented on the V2 Fetch Survey Response reference page. The corresponding fields in sprinklr-v3.yaml are declared as unconstrained type: string with no enum, so these values are carried forward from V2 documentation rather than from the V3 specification. They should be added as enums to the V3 schema

AI-generated quality assessment of the response.

1. Bulk import of historical responses from a legacy platform. Iterate a legacy export and POST each response with its original responseTime and surveyLanguage. Per the Help Center this "Facilitates the automatic integration of large quantities of survey responses from external systems into Sprinklr."

2. Real-time sync from an offline collection tool. Kiosk or field-agent applications collect feedback without connectivity, then ingest queued responses when the device reconnects, preserving the true responseTime rather than the upload time.

3. CRM-triggered feedback capture. When a CRM records a closed case, submit the associated survey response with transactionCustomFields carrying the case attributes, so the response is analysable alongside the interaction that produced it.

4. Feeding a downstream analytics warehouse. Page through POST /search on a schedule, resolve question IDs via metadata.questionLookup, and load flattened rows into a warehouse. This "Enables downstream analytics tools to retrieve or modify response data as required."

5. Backfilling custom fields on historical responses. A new segmentation attribute is defined after responses were collected. Script a PUT across the affected responseId values to populate it — the Help Center's documented pattern of "bulk updates on older responses in light of the latest information for analytical purposes."

6. Enriching responses with profile data resolved later. A response arrives anonymously and the responder is identified afterwards. Use PUT to attach profileCustomFields once the identity is known.

7. Correcting a mis-mapped custom field. An ingestion job wrote the wrong internal field name. Fetch the affected responses, then PUT the corrected mapping — subject to confirming replace-versus-merge semantics.

8. Purging test and duplicate submissions before reporting. Search for responses with responseStatus of TEST_RESPONSES, then DELETE them so they do not distort dashboards.

9. Filtering out low-quality and bot responses. Use responseQuality to identify Bot and Low submissions and either delete them or tag them for exclusion, protecting score integrity.

10. Auditing a single response after a customer complaint. Fetch by responseId to inspect exactly what was answered, on what device and browser, and at what time — the audit use case the Help Center describes as "Obtain a particular reply for examination, auditing, or modification."

11. Data-subject erasure. Search for a responder's submissions, then delete each by ID. Confirm the permanence of deletion before relying on this for a compliance workflow.

Verify required fields before ingestion. The Help Center is explicit: "Always verify the necessary fields prior to ingestion." SurveyResponseIngestionRequest declares no required array, so the server will accept structurally valid but semantically empty payloads. Validate client-side.

Batch large ingestions. Per the Help Center: "Utilize APIs in groups for large-scale data ingestion to minimize overhead." No maximum batch size or request-size limit is documented, so keep batches conservative until one is confirmed.

Filter searches narrowly. Per the Help Center: "Utilize filtering with appropriate fields to refine GET APIs and prevent timeouts." An unfiltered search over a high-volume survey is the most likely cause of a timeout on this API.

Custom field values are always arrays of strings. ["5"], never "5" and never 5. This applies on ingest and on update, across all three namespaces.

Request and response custom-field names differ. Requests use responseCustomFields / profileCustomFields / transactionCustomFields; responses use customProperties / profileCustomProperties / transactionCustomProperties. Write an explicit bidirectional mapping.

Never hard-code question IDs. Resolve them through metadata.questionLookup on every fetch. Question IDs change when a survey is edited or cloned, and some IDs are compound (<questionId>_<optionId>, as in the V2 sample c958057e-…_778dcad1-…).

PUT is not a general-purpose update. It writes custom fields only. Answers, status, and system fields cannot be modified through this API.

Treat PUT as potentially destructive until proven otherwise. With replace semantics, a payload containing one custom field could erase all the others.

PATCH does not exist. Do not build against the PATCH operation.

Guard DELETE client-side. id is declared optional on a destructive operation. Assert it is non-empty before dispatching, and consider requiring an explicit confirmation flag in any script that deletes in bulk.

Test the round trip in the UI. The Help Center recommends starting with a test survey and a test responder address such as test@sprinklr.com, confirming the API returns 200 OK, and then "verify that the response is visible in the Sprinklr UI under the Survey Responses tab." An API success does not by itself prove the response was indexed.

Do not assume idempotency. No idempotency key, deduplication window, or uniqueness constraint is documented for ingestion. A retried POST will most likely create a duplicate response and distort your scores. Deduplicate at the client.

Rate limits are undocumented. No rate-limit headers, quotas, or 429 responses are declared. Build in client-side throttling and exponential backoff regardless.

Timestamps are epoch milliseconds in V3. responseTime, createdTime, surveyStartTime, surveyOpenTime, and elapsedTime are all int64. V2's formatted-string responseTime will be rejected.

Keep credentials and session artefacts out of examples. Strip Cookie: JSESSIONID headers, and never paste live tokens into tickets or shared Postman collections.

Authorization: Bearer {{accessToken}}
Key: {{apiKey}}
Content-Type: application/json      # POST and PUT only
Accept: application/json