CFM Workflow API V3 — Developer Guide

• Applies to: Sprinklr Customer Feedback Management (CFM) Workflow API V3 (/api/v3/cfmWorkflow)
• V2 API reference: CFM Workflow API | Sprinklr Developer Portal
• CFM module overview: Customer Feedback Management | Sprinklr Developer Portal

The CFM Workflow API starts a Customer Feedback Management workflow from an external system event. You supply a workflow identifier and a set of context parameters; Sprinklr runs the configured workflow, which can create or update a customer profile and trigger a personalized survey distribution over Email, SMS, or WhatsApp.

This turns real customer-journey moments — an online purchase, a form submission, an abandoned cart, a support-case closure — into a targeted, automated feedback request.

V3 exposes two POST operations under a single resource prefix:

Both are tagged CFM Workflow V3 in the OpenAPI specification.

The central design change from V2: V2 documented a single endpoint — POST /api/v2/cfm-workflow/triggerWithNewProfile — which always required a unifiedProfile object. V3 splits the capability in two, so a caller who only needs to fire an event against an already-known workflow context can use the lighter /trigger operation and omit profile construction entirely.

Prerequisite. CFM must be enabled in your environment before you can use these APIs. Contact your Success Manager.

A trigger request is composed of at most three parts:

The workflow itself — its conditions, its branching, and the Trigger Survey Distribution action that actually sends the survey — is configured in the Sprinklr UI under Sprinklr Insights → Customer Feedback Management → survey → Automation, using the CFM Workflow API event type. The API only starts it. See Setting Up a CFM Workflow API Event Workflow for the configuration side.

workflowId is the identifier of a workflow you have already created and activated in the CFM Automation canvas. It is a UUID-shaped string, for example 595b4041-6eba-400f-aff0-797f1029c6f2.

You can obtain a ready-made request — with workflowId pre-filled from the current workflow — by opening the workflow record and choosing Test API Connection. That screen also lets you pick a Channel Type (Email, WhatsApp Business, SMS), supply a first name, full name, and social network user ID, and add extra contextParams, then click Get API Request. Copy the generated request, add your authentication headers, and run it. (Source: Setting Up a CFM Workflow API Event Workflow)

All production API calls are sent to:

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

So the workflow resources in production are:

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

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

QA and pre-production environments use a different host shape, in which the environment is a hostname prefix rather than a path segment:

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

Permissions: the CFM Workflow API event does not require any special permission within the Sprinklr Audience Profile Event module. However, you must configure the CFM Workflow API within your own systems and hold valid Sprinklr API authentication. (Source: Setting Up a CFM Workflow API Event Workflow)

Triggers an active CFM workflow using only a workflow identifier and runtime context. Use this when the customer profile the workflow acts on is already resolvable from the workflow's own configuration or from the supplied context, and you do not need to create or update a profile in the same call.

POST /api/v3/cfmWorkflow/trigger

• operationId: CfmWorkflowApiV3_triggerWorkflow
• Summary (OpenAPI): Run workflow via event
• Request schema: CfmWorkflowTriggerV3Request
• Request body: required
• Response schema: APIResponse

Schema CfmWorkflowTriggerV3Request — Request body for triggering a CFM workflow via API v3.

workflowId is the only field in the OpenAPI required array.

IGNORE_DEDUP, lang, country, countryCode, and surveyFilled are the keys shown in every supplied example. They are conventional keys, not a closed enum — contextParams is an open map, so you can pass any key your workflow's conditions reference.

curl --request POST \
  --url 'https://api3.sprinklr.com/{env}/api/v3/cfmWorkflow/trigger' \
  --header 'Authorization: {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{
    "workflowId": "595b4041-6eba-400f-aff0-797f1029c6f2",
    "contextParams": {
      "IGNORE_DEDUP": true,
      "lang": "ar",
      "country": "Jordan",
      "countryCode": "SA",
      "surveyFilled": "true"
    }
  }'

{
  "data": "Success",
  "errors": []
}

Dev note: a "Success" value in data indicates that the API endpoint successfully triggered the CFM workflow for the profile. It does not confirm that the survey was delivered — delivery happens asynchronously inside the workflow. See §10.

Triggers an active CFM workflow and supplies a new unified customer profile in the same request. Sprinklr creates or updates the profile from the payload and then runs the workflow against it — which is what lets the workflow's Trigger Survey Distribution action reach a customer the platform has never seen before.

POST /api/v3/cfmWorkflow/triggerWithNewProfile

• operationId: CfmWorkflowApiV3_triggerWorkflowWithProfile
• Summary (OpenAPI): Run workflow via event with profile details
• Request schema: CfmWorkflowTriggerProfileV3Request
• Request body: required
• Response schema: APIResponse

This is the direct V3 successor to the single V2 endpoint POST /api/v2/cfm-workflow/triggerWithNewProfile.

Schema CfmWorkflowTriggerProfileV3Request — Request body for triggering a CFM workflow with a new profile via API v3.

workflowId is the only field in the OpenAPI required array.

unifiedProfile is the platform-wide UnifiedProfile schema — "Unified view of a profile in sprinklr." It is the same object the Profile V3 API returns, and it is large. Only a small subset is relevant to a workflow trigger.

Fields used in practice (per every supplied example):

¹ name, channelType, channelId, and permalink are listed in the required array of the Profile schema. Note that no supplied example sends permalink — including the V2 portal page, which marks it Optional, and the Help Center in-product sample. Treat the OpenAPI required list on Profile as unverified for this use case.

UnifiedProfile additionally carries works, organizations, certificates, recommendations, educations, languages, skills, courses, honors, patents, projects, publications, testScores, voluntaryExp, and operatingHours. None of these are referenced by any supplied CFM example; they are inherited from the shared profile model and are not documented further here. See the Profile API V3 guide for their semantics.

unifiedProfile.contact.address, schema Address — Describes the schema for Address.

unifiedProfile.profiles[].accountSpecificInfos[], schema AccountSpecificInfo.

unifiedProfile.profileWorkflow, schema ProfileWorkflow — Describes the schema of partner-level workflow in profile.

unifiedProfile.profileWorkflow.profileSpaceWorkflows[], schema ProfileSpaceWorkflow:

curl --request POST \
  --url 'https://api3.sprinklr.com/{env}/api/v3/cfmWorkflow/triggerWithNewProfile' \
  --header 'Authorization: {{accessToken}}' \
  --header 'Key: {{apiKey}}' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data-raw '{
    "workflowId": "595b4041-6eba-400f-aff0-797f1029c6f2",
    "contextParams": {
      "IGNORE_DEDUP": true,
      "lang": "ar",
      "country": "Jordan",
      "countryCode": "SA",
      "surveyFilled": "true"
    },
    "unifiedProfile": {
      "contact": {
        "firstName": "Alex",
        "lastName": "Doe",
        "email": "alex.doe@example.com",
        "phoneNo": "9876543210"
      },
      "profiles": [
        {
          "name": "Alex Doe",
          "channelType": "EMAIL",
          "channelId": "alex.doe@example.com"
        }
      ]
    }
  }'

Multi-channel variant — attach several channel identities so the workflow can select a distribution channel:

{
  "workflowId": "{{workflowId}}",
  "contextParams": {
    "IGNORE_DEDUP": true,
    "lang": "en",
    "country": "India",
    "countryCode": "IN",
    "surveyFilled": "false"
  },
  "unifiedProfile": {
    "contact": {
      "firstName": "Alex"
    },
    "profiles": [
      { "channelType": "WHATSAPP_BUSINESS", "channelId": "918012345678", "name": "Alex Doe" },
      { "channelType": "SMS",               "channelId": "918012345678", "name": "Alex Doe" },
      { "channelType": "EMAIL",             "channelId": "alex.doe@example.com", "name": "Alex Doe" }
    ]
  }
}

{
  "data": "Success",
  "errors": []
}

Both operations declare the shared APIResponse schema:

{
  "data": {},
  "errors": [],
  "metadata": {}
}

Specification gap. APIResponse.data is declared as type: object, but both CFM Workflow operations return a JSON string. The ResponseMetadata schema is declared with an empty properties map, so no metadata fields can be documented from the specification, and no supplied example returns a metadata key at all for these endpoints. Parse defensively: treat metadata as possibly absent.

Declared in the OpenAPI specification for both operations:

For the full status-code catalogue see REST API Error and Status Codes on the developer portal.

These three are the channels named in the CFM Workflow API description and used in the V2 and Help Center samples. channelType on the Profile schema is declared as an open type: string, not a closed enum, so the platform-wide channel list also applies. Values are uppercase and case-sensitive.

contextParams is an open map. Any additional key you pass becomes available as a workflow variable to the workflow's conditions and actions. Add extra keys through Test API Connection in the workflow record to see them reflected in a generated request.

Once triggered, the workflow can run any of the elements supported by the CFM Workflow API (Audience Profile) event:

(Source: Setting Up a CFM Workflow API Event Workflow)

A customer abandons a shopping cart. Your commerce platform calls POST /cfmWorkflow/triggerWithNewProfile with the shopper's contact details and contextParams describing the cart. The workflow updates the profile and triggers a personalized survey or incentive over email or SMS to encourage the customer to complete the purchase. If the customer responds, the team follows up with targeted offers or addresses the issue that caused the abandonment.

After a purchase completes, your order-management system triggers the workflow with transaction context. The workflow sends a personalized survey over the customer's preferred channel. Use contextParams to carry order value, product category, and store identifier so the workflow's conditions can route high-value orders to a longer survey.

Send a trigger after each key interaction — purchase, profile update, service visit. Because every trigger consolidates into the same unified profile (keyed on channelId), you accumulate a complete view of the customer's interactions across channels while still gathering point-in-time feedback.

Your CRM already synchronizes profiles into Sprinklr nightly. At event time you only need to fire the workflow. Use POST /cfmWorkflow/trigger with workflowId and contextParams only — no profile construction, smaller payload, fewer moving parts. This case had no V2 equivalent.

Set lang, country, and countryCode in contextParams. The workflow branches on these values to select a localized survey template and an appropriate distribution channel per market — for example the "lang": "ar", "country": "Jordan", "countryCode": "SA" combination used in the reference examples.

Set "IGNORE_DEDUP": true when you intentionally want a second survey to reach a customer who has already been contacted — for example a re-survey after a service recovery. Leave it unset (or false) for normal traffic so the platform's duplicate detection protects the customer from survey fatigue.

Attach WHATSAPP_BUSINESS, SMS, and EMAIL identities in a single profiles[] array, as in the (#56-example-request) multi-channel variant. The workflow's distribution action can then choose the channel, and you have not had to decide it at trigger time.

Open the workflow record, choose Test API Connection, fill in channel type, first name, full name, social network user ID, and any extra contextParams, then click Get API Request. The workflowId is filled in automatically. Add your authentication headers and run the generated request from Postman. A successful execution confirms the API connection before you wire the trigger into your production system flow.

When your ticketing system closes a case, trigger the workflow with the case reference in contextParams. The workflow sends a post-support satisfaction survey and, based on the response, can create a follow-up record or route the customer to a recovery journey.

"Success" is an acknowledgement, not a delivery receipt. The dev note in the endpoint specification is precise: "Success" indicates the API endpoint was successful in triggering the CFM workflow. Survey delivery happens asynchronously inside the workflow. Do not treat a 200 OK as proof the customer received anything. Instrument delivery on the workflow side.

channelId is the deduplication key. Per the V2 documentation, if the channelId is unique a new profile is created and a journey is associated with it; otherwise the journey attaches to the existing profile. Get channelId normalization right — inconsistent phone-number formatting between systems (with and without country code, with and without +) will silently fragment one customer into several profiles.

Send the same phone number consistently across SMS and WHATSAPP_BUSINESS. They are separate profiles[] entries with separate channelType values but typically the same channelId. Both must be present if you want the workflow to be able to choose between them.

channelType is uppercase and case-sensitive. email is not EMAIL.

Do not enable IGNORE_DEDUP globally. It exists for deliberate re-sends. Left on by default it will over-survey your customers and depress response rates.

Treat contextParams as your workflow's public interface. Every key you send becomes a workflow variable that conditions may reference. Adding a key is safe; renaming or removing one silently breaks the branch that reads it. Version your key names and coordinate changes with whoever owns the workflow canvas.

Profile-level custom fields are not supported. The V2 documentation states this explicitly for profileWorkflow.customProperties, and no supplied V3 source contradicts it. Use profileSpaceWorkflows[].customProperties (workspace-scoped) instead.

Build retry handling despite the specification. No 500 is declared on either operation, and no rate limit, idempotency, or retry behavior is documented in any supplied source. Implement exponential backoff on 5xx and on network timeouts. Note that these operations are not documented as idempotent — a retried POST /triggerWithNewProfile may fire the workflow twice. Guard retries with your own request-deduplication key until idempotency semantics are confirmed.

Never log request bodies verbatim. unifiedProfile.contact carries names, email addresses, and phone numbers — personally identifiable information. Redact before logging.

Never embed credentials in code, tickets, or chat. See the credential-hygiene callout in (#3-authentication-and-common-headers), including the outstanding rotation action for the three secrets exposed.

Parse the response envelope defensively. metadata is declared on APIResponse but is absent from every supplied CFM example, and ResponseMetadata has no declared properties. Do not require the key to be present.

Confirm the conflicts in (#12-questions-for-the-api-owner) before publishing this guide. Nine material contradictions between the ticket, the OpenAPI specification, the endpoint specifications, and the V2 baseline are flagged inline. Several affect the request contract directly.