CFM Transaction APIs V3 — Developer Guide

• Applies to: Sprinklr Customer Feedback Management (CFM) Transaction APIs V3 (/api/v3/surveyTransactions)
• V2 API reference: CFM Transaction APIs | Sprinklr Developer Portal

A transaction is a CFM-specific record that documents a single customer interaction at a specific moment in time — a purchase, a refund, a service visit, a support contact, or a loyalty redemption. Transactions are contained within a user profile and carry a unique set of metadata stored as key-value pairs in Transaction Fields. Because each interaction is stored independently rather than overwriting the profile, a customer who shops twice produces two transactions, and each one can drive its own survey distribution.

Transactions are grouped into Transaction Groups: a named set of transactions created in the CFM Persona App under Audience Management → Transaction. Survey workflows subscribe to one or more transaction groups, and a Transaction Record Event workflow fires every time a new transaction is ingested into a subscribed group.

The CFM Transaction APIs V3 expose three operations on a single resource path — /api/v3/surveyTransactions — differentiated by HTTP method:

This single-path, method-differentiated shape is the central design change in V3 and matches the pattern already used by Profile V3 (/api/v3/profile) and Survey Response V3.

There is no bulk list operation on /api/v3/surveyTransactions. GET returns exactly one transaction, addressed by its ID. To enumerate every transaction in a group, use the Search by Entity API.

The Transaction schema in sprinklr-v3.yaml is the single object used both as the request array element on POST and as the response payload on GET.

A transaction is addressed one way only: by its Sprinklr transaction ID, returned in data[].id on create — for example 6a88545dd4bb4391d3760b0b. There is no alternate business key. Persist the ID returned by POST if you intend to fetch or delete the record later.

Three things must exist before the first API call succeeds.

1. CFM must be enabled in your environment. Per the Sprinklr Developer Portal: "CFM must be enabled in your environment before you can utilize these APIs. Please contact your Success Manager for more details."
2. A user profile must exist for the userId. A transaction attaches to a profile. If no profile exists for the identifier you send, create one first with the Create Profile API (see the Profile API V3 developer guide). Sprinklr's file-import path creates a profile automatically when one is absent; the supplied endpoint specification for POST /surveyTransactions states the profile is a prerequisite for the API path.
3. A transaction group must exist, and it must be of type API. Create it in the CFM Persona App under Audience Management → Transaction → Create Transaction Group. Per the Help Center: "If you plan to send transactions programmatically from an external system in real time, create a Transaction Group of type API, and setup the API." Share the group with the survey projects where the workflow will run — only shared groups are selectable inside workflows. Transactions can only be created inside an existing group; the API does not create groups.

All API calls are sent to the production endpoint:

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

So the transaction resource in production is:

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

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 Transaction API calls are authenticated with OAuth 2.0. See API Overview for portal registration, API key and secret generation, and the Authorize flow.

Adds one or more transactions to an existing transaction group. Each transaction represents a single interaction record for a user.

POST /api/v3/surveyTransactions

Request schema: SurveyTransactionsCreateRequestDTO — "Create survey transactions in a transaction group." Required: transactionGroupId, transactions

orderId, purchaseAmount, and purchaseCategory are illustrative custom properties taken from the supplied specification. They are not fixed fields. The keys your group accepts are the Transaction Fields configured for it under Global Settings → Transaction Fields.

curl --location 'https://api3.sprinklr.com/{env}/api/v3/surveyTransactions' \
  --header 'Authorization: Bearer {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "transactionGroupId": "68adc96c444bb074f1fd28f7",
    "transactions": [
      {
        "userId": "jordan.rivera@example.com",
        "profileName": "Jordan Rivera",
        "distributionChannel": "EMAIL",
        "customProperties": {
          "orderId": "ORD-40219",
          "purchaseAmount": "129.00",
          "purchaseCategory": "Footwear"
        }
      }
    ]
  }'

{
  "data": [
    {
      "id": "6a88545dd4bb4391d3760b0b",
      "userId": "jordan.rivera@example.com",
      "profileName": "Jordan Rivera",
      "transactionGroupId": "68adc96c444bb074f1fd28f7",
      "distributionChannel": "EMAIL",
      "customProperties": {},
      "isArchived": false,
      "ownerUserId": 66009896,
      "createdTime": "Aug 21, 2026, 01:36:29 PM",
      "lastModifiedUserId": 66009896,
      "deleted": false,
      "canEdit": false
    }
  ],
  "errors": []
}

Illustrative response, reproduced from the supplied specification with the user identifier replaced by a placeholder. No API call was executed to produce it.

Note that data is an array on create — one element per transaction submitted, in request order — whereas GET returns a single object. Read data[].id and persist it.

In the supplied sample, customProperties is returned as an empty object even though the request could carry properties, because the sample request had its properties commented out. Whether customProperties is echoed back on create is unconfirmed.

Retrieves detailed information about a specific transaction using its unique transaction ID. Use it to validate and review transaction attributes, including user details, distribution channel, and status.

GET /api/v3/surveyTransactions?id={transactionId}

Response schema: Transaction

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

{
  "data": {
    "id": "6a8c446a69baf80612fb63f7",
    "userId": "jordan.rivera@example.com",
    "profileName": "Jordan Rivera",
    "transactionGroupId": "68adc96c444bb074f1fd28f7",
    "distributionChannel": "EMAIL",
    "customProperties": {},
    "isArchived": false,
    "ownerUserId": 66009896,
    "createdTime": "Aug 24, 2026, 01:17:30 PM",
    "lastModifiedUserId": 66009896,
    "deleted": false,
    "canEdit": false
  },
  "errors": []
}

Illustrative response, reproduced from the supplied specification with the user identifier replaced by a placeholder.

The response parameters are identical to those in §4.4, except that data is a single object rather than an array.

There is no bulk-list operation on /api/v3/surveyTransactions. To fetch all transactions in a transaction group:

1. Call the Search by Entity API with TRANSACTION as the entityType and transactionGroupId in the filters object.
2. Read the cursor returned in the response.
3. Pass that cursor to the Search by Cursor API to retrieve the next page, and repeat until the cursor is exhausted.

Specification gap. The supplied specification names these two APIs but does not give their paths, request schemas, or the exact filters syntax for transactionGroupId. The guide cannot document the call without inventing it.

Deletes a specific transaction using its unique transaction ID.

DELETE /api/v3/surveyTransactions?id={transactionId}

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

The three sources disagree on what DELETE returns.

Documented on the assumption the envelope form is correct:

All CFM Transaction V3 responses use the standard APIResponse envelope declared in `sprinklr-v3:

Because POST accepts an array, a partial failure is possible in principle — some transactions created, others rejected. No supplied source states whether the operation is atomic per request or per element, or how a partial failure is signalled in errors.

The structural change is the same one applied across the V3 programme: one resource path, three HTTP methods, replacing three separately-named V2 endpoints. Routing, retry, and observability code that keys on the path must now key on the method as well.

Source: Help Center — "Workflows accept three types of transaction groups: Unified Data Connector (UDC), API, and Import." The exact string tokens the API returns in transactionGroupType are not declared in sprinklr-v3.yaml (unconstrained type: string) and do not appear in any response sample.

1. Post-purchase feedback from an e-commerce platform. On order confirmation, POST a transaction carrying orderId, purchaseAmount, and purchaseCategory into an API-type transaction group. A Transaction Record Event workflow subscribed to that group fires and triggers a personalized survey distribution on the channel in distributionChannel.

2. Refund and service-recovery surveys. Push a transaction whenever a refund is processed, tagged with the refund reason in customProperties. A workflow decision node branches on the reason and routes high-value refunds to a longer service-recovery survey.

3. Post-support-interaction surveys. After a support ticket closes, create a transaction carrying ticket status, interaction date, and issue type. Per the Help Center, this lets surveys be "dynamically tailored based on the nature of the support interaction, such as a technical issue or an account query."

4. Multiple surveys for the same customer across separate events. A customer shops at two locations on different days. Create one transaction per visit. Because each transaction is stored independently rather than overwriting the profile, both events survive and each can drive its own targeted survey — the outcome that is impossible with profile fields alone.

5. Loyalty programme engagement. Create a transaction on each loyalty redemption. A workflow filters on the redemption tier in customProperties and sends a survey focused on the specific benefits the member received.

6. Service-visit follow-up for field operations. After a technician closes a visit, push a transaction with the visit type and location so the follow-up survey question set matches the work performed.

7. Pre-flight validation of an ingestion pipeline. After a batch POST, call GET ?id= for a sample of returned IDs and assert that userId, distributionChannel, and customProperties match what was sent. This is the documented purpose of the fetch endpoint — "validate and review transaction attributes."

8. Correcting a mis-ingested record. A transaction created with a wrong userId or an incorrect channel would otherwise trigger a survey to the wrong recipient. DELETE it by ID and re-create it correctly. There is no update operation on /surveyTransactions — correction is delete-and-recreate.

9. Data-subject erasure requests. When a customer requests deletion of their interaction history, enumerate their transactions via the Search by Entity API and DELETE each by ID. Confirm with the API owner whether this is a hard or soft delete before relying on it for a compliance workflow.