Content Template API v3 — Developer Guide

Applies to: Sprinklr API v3 (Content Template V3 tag) — GET /contentTemplate, POST /contentTemplate/search

V2 API reference: Content Template on the Sprinklr Developer Portal [doc:turn1doc1]

Sprinklr Content Template Builder powers cross-channel content management: it lets users consolidate images, videos, and content for non-social channels such as websites, blogs, and email into reusable templates. The Content Template APIs let you fetch details for user-created and standard content templates, and search templates using sorts, filters, and pagination [doc:turn1doc1].

The v3 Content Template API replaces four separate v2 endpoints with a single resource path plus a search sub-resource.

Both operations are tagged Content Template V3 and declare the four shared error responses: 400 BadRequest, 401 Unauthorized, 403 Forbidden, 404 NotFound.

For more details refer to the Content Template V3 API Reference.

A content template is identified by a 24-character hexadecimal id. Beyond id and name, the returned object is template-type dependent.

Note (from the source operation document). "The response parameters vary from template to template. The details depend on the template details present on the backend." Treat every field other than id and name as optional and defensively parse the payload.

Fields observed in the reference GET response for an email content template:

Typical workflow:

1. Call POST /contentTemplate/search with filters (for example TEMPLATE_TYPE IN [CONTENT_TEMPLATE]) and a page size to obtain a lightweight list of {id, name} pairs plus hasMore and totalHits.
2. Call GET /contentTemplate?id={templateId} for each identifier you need in order to retrieve the full template body.

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

env is a required path variable. Default: prod. Allowed values declared in the specification:

prod, prod0, prod2, prod3, prod4, prod5, prod6, prod8, prod11, prod12, prod15, prod16, prod17, prod18, prod19, prod21, prod25

Full endpoint URLs:

GET  https://api3.sprinklr.com/{env}/api/v3/contentTemplate
POST https://api3.sprinklr.com/{env}/api/v3/contentTemplate/search

Important. Use your own partition's environment token.

GET /api/v3/contentTemplate · operationId ContentTemplateApiV3_fetchContentTemplates

Fetches standard content template details using the template id.

Endpoint form given in the source operation document:

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

Endpoint form given in the Jira description:

GET /api/v3/contentTemplate?id=templateId1,templateId2

Additional query parameters named in the Jira description as replacements for v2 URL variants, not present in the specification and not exercised in the operation document:

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

Illustrative example. Replace {env}, {{accessToken}}, {{apiKey}}, and the template id with your own values.

The content field in the real response is a very large escaped-JSON string containing the full component tree and embedded @font-face declarations. It is elided below as "…"; everything else is reproduced from the source document.

{
  "data": {
    "id": "6a2bfe33703a82b2e91dc02a",
    "name": "manual ctm template",
    "channelType": "EMAIL",
    "accountTypes": [
      "BULK_EMAIL"
    ],
    "content": "…",
    "smartTemplate": false,
    "isAdvocacyTemplate": true,
    "templateType": "CONTENT_TEMPLATE",
    "advocacyProjectId": "f5122f12-f3fb-4ef9-87f5-56b05b2ba4f9",
    "height": 1457,
    "width": 600,
    "projectId": "d5b402ad-cb5f-4976-8a23-0ea316767890",
    "locationUrl": "https://storage.googleapis.com/…/spx-publisher/d5b402ad-cb5f-4976-8a23-0ea316767890/1785317396873",
    "publisherStatus": "completed",
    "contentType": "PUBLISHING",
    "version": 0,
    "templateVersionInfo": "0.0.1",
    "editDisabled": true,
    "archived": false,
    "isPurelyAIGenerated": false,
    "report": "CONTENT_TEMPLATE",
    "governance": {
      "visibility": {
        "globallyVisible": true
      }
    },
    "clientId": 66000002,
    "ownerUserId": 66009128,
    "createdTime": "Jun 12, 2026, 12:40:19 PM",
    "modifiedTime": "Jul 29, 2026, 09:29:56 AM",
    "lastModifiedUserId": 66009128,
    "deleted": false,
    "canEdit": false
  },
  "errors": []
}

data carries the template object described in §1.2. errors is an array of Error objects; an empty array indicates that no errors occurred. See §6.

POST /api/v3/contentTemplate/search · operationId ContentTemplateApiV3_searchContentTemplates

Fetches content template id and name details using sorting and filter values. The request body is required and the declared body schema is Request; the declared 200 schema is PaginatedSearchResponse.

Discrepancy — filters requiredness. The operation document marks filters Required while marking every one of its sub-fields Optional, and the same document's dev note says an empty body {} is valid (see §5.4). Those two statements cannot both hold. The specification marks the body required but declares no required array inside Request, so filters is optional at the schema level. Confirm the intended contract.

Discrepancy — filterType enum. In the specification, filters[] resolves to Filter_request, whose filterType is the enum FilterType_Filter with values FILTER, LIMIT, SEARCH, MATCH_PHRASE_PREFIX, ADHOC_SEARCH, EXPRESSION, GEO_DISTANCE, ADVANCED_QUERY, MATCH_NONE, MATCH_ALL. Only FILTER appears in both lists. The value used in the working example — IN — is not in the specification enum, yet QA verified the call. Treat the operation document's list as the behavioural truth and the specification enum as stale, but confirm before generating client code from the spec.

Note — Request is a shared, very wide schema. Request is Sprinklr's generic search/reporting request object. It declares roughly 40 top-level properties (key, timeFilter, previousTimeFilter, query, queries, filters, filter, postFilters, projectionFilters, groupBys, projections, report, permission, tzOffset, timezone, sorts, page, pageForDocuments, sortsForDocuments, merge, excludeFields, additional, and more). Only sorts, page, and filters are documented for this operation. The remaining properties are not documented as supported for content template search — do not assume they are honoured.

Related schema details from sprinklr-v3.yaml:

• sorts[] → Sort_request: type (string), key (string), order (Order_enums — a bare string with no enum values declared), additional, postProjectionSort.
• page → Page_request: page (int32), size (int32), skip (int32), cursor (string). Only page and size are documented for this operation.
• filters[] → Filter_request: field, filterType, values (array of object), plus displayName, negativeFilter, isCompoundFilter, accessibleValues, userFilter, allValuesAllowed, lockedWithValues, hidden, favourite, mandatory, locked, disabled, details — all undocumented for this operation.

curl --location 'https://api3.sprinklr.com/{env}/api/v3/contentTemplate/search' \
--header 'Authorization: Bearer {{accessToken}}' \
--header 'Key: {{apiKey}}' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{
    "sorts": [
        {
            "key": "MODIFIED_TIME",
            "order": "DESC"
        }
    ],
    "page": {
        "page": 0,
        "size": 5
    },
    "filters": [
        {
            "field": "TEMPLATE_TYPE",
            "filterType": "IN",
            "values": [
                "CONTENT_TEMPLATE"
            ]
        }
    ]
}'

Illustrative example, reproduced from the source operation document with credentials replaced by placeholders.

{
  "data": {
    "searchResults": [
      {
        "id": "6a214d2e1d46a76667fd4b9c",
        "name": "pragya testing "
      },
      {
        "id": "6a883d0595239a114d6dbf47",
        "name": "Link"
      },
      {
        "id": "6a883d05e7f1f360e3d4f1c2",
        "name": "Media"
      },
      {
        "id": "6a883d05e7f1f360e3d4f1c3",
        "name": "Text"
      },
      {
        "id": "6a7afc34dff6d5eda924d20e",
        "name": "Thread"
      }
    ],
    "hasMore": true,
    "totalHits": 287
  },
  "errors": []
}

Response fields:

Discrepancy — field names. The declared 200 schema PaginatedSearchResponse uses abbreviated property names: sR (array), tBC (int64), iBC (string), hM (boolean), tH (int64), fR (array of SearchFacetResponse), topHits (map of Tuple_Long_List_T). The verified response instead uses searchResults, hasMore, and totalHits, and is wrapped in a data envelope that PaginatedSearchResponse does not declare. This is almost certainly a serialization-alias mismatch in the published spec. Code against the documented names (data.searchResults, data.hasMore, data.totalHits) and treat the abbreviated spec names as an outstanding spec bug. Also note sR[] is typed "Unresolved type (T)", so the {id, name} shape comes only from the example.

Dev note. "If the request has no sorting or filters applied and has a pair of empty curly brackets, i.e., {}, then the response will show details for all the content templates available on a single page. By default, the size of response per page is equal to 100."

So:

• Body {} → all available content templates, one page.
• Default page size when page is omitted → 100.
• Use hasMore and totalHits to decide whether to request the next page.

curl --location 'https://api3.sprinklr.com/{env}/api/v3/contentTemplate/search' \
--header 'Authorization: Bearer {{accessToken}}' \
--header 'Key: {{apiKey}}' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data '{}'

No other status codes are declared for either operation.

APIResponse:

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

ErrorResponse:

{
  "data": null,
  "errors": [
    {
      "id": "6a2bfe33703a82b2e91dc02a",
      "code": 404,
      "message": "content.template.not.found"
    }
  ],
  "metadata": {}
}

Error requires all three fields:

Note. The message value shown above is an illustrative key following the platform's dotted-key convention. The specification does not enumerate content-template-specific error codes or keys. Log code and message verbatim; do not pattern-match on message text.

1. Change the base path from /api/v2/ to /api/v3/ and confirm your {env} token is in the v3 environment enum (§2).
2. Move the template id out of the path. Replace GET /api/v2/contentTemplate/{templateId} with GET /api/v3/contentTemplate?id={templateId}.
3. Retire the ?fromGlobal=true URL variant. Call the single GET and read governance.visibility.globallyVisible from the response. Confirm with the API owner whether a fromGlobal query parameter is actually accepted before depending on it.
4. Retire /findAll?channelTypes=. Replace it with POST /api/v3/contentTemplate/search using a filters entry, or confirm the channelTypes query parameter with the API owner.
5. Rename the search sub-path from searchContentTemplates to search. The sorts / page / filters body structure is unchanged in the documented examples.
6. Update your search response parser. data is now an object, not an array. Read data.searchResults instead of data, and start consuming hasMore / totalHits.
7. Adopt pagination. v2 findAll returned an unpaginated list. In v3, omitting page returns 100 results; loop on hasMore and increment page.page.
8. Harden your GET parser. The full template object varies by template type, and content is an escaped JSON string that must be unescaped before parsing.
9. Update error handling to the ErrorResponse / Error shape (id, code, message) and to the 400/401/403/404 set.
10. Do not plan on v3 write operations. PUT, PATCH, and DELETE are not delivered. Keep using existing platform mechanisms for template mutation.

No complete list of filterable fields is published in any source.

The two lists overlap only on FILTER. See the discrepancy note in §5.1.

These values are observed in the reference example only; none is declared as an enum in the specification.

• Template catalogue sync. Page through POST /contentTemplate/search with {} or a TEMPLATE_TYPE filter to mirror the id/name catalogue into an external CMS or DAM, then fetch full bodies on demand.
• Most-recently-edited view. Sort by MODIFIED_TIME DESC with a small page.size to power a "recently updated templates" panel.
• Channel-scoped picker. Filter the search results to the channel your integration publishes to, replacing the v2 findAll?channelTypes= call.
• Template rendering/preview. Retrieve the full object with GET, unescape content, and hand the component tree to your renderer; use height, width, and locationUrl for layout and asset resolution.
• Governance auditing. Read governance.visibility.globallyVisible, editDisabled, canEdit, archived, deleted, ownerUserId, and lastModifiedUserId to report on template access and lifecycle.

1. Search first, fetch second. The search response is a lightweight {id, name} list; the GET response can be hundreds of kilobytes because of the embedded content string. Do not fetch full bodies to build a list view.
2. Always send page. Relying on the default of 100 makes your integration silently sensitive to a server-side default change.
3. Loop on hasMore, verify against totalHits. Stop when hasMore is false; use totalHits for progress and sanity checks.
4. Unescape content before parsing. It is a JSON string, not a nested object.
5. Parse the GET response defensively. Per the source dev note, fields vary by template. Guard every field except id and name.
6. Treat createdTime / modifiedTime as formatted strings. They arrive as Jun 12, 2026, 12:40:19 PM, not epoch milliseconds. Parse with an explicit format and confirm the emitting timezone with the API owner.
7. Do not send Cookie: JSESSIONID=…. Authenticate with Authorization + Key only.
8. Do not use undocumented Request properties. Only sorts, page, and filters are documented for this operation.
9. Filter on the server. Send filters rather than pulling all templates and filtering client-side.
10. Handle errors even on 200. The envelope carries an errors array independently of the HTTP status; check that it is empty before trusting data.
11. Pin the environment. Ensure {env} matches your partition; a wrong environment yields 401/403 rather than empty results.