Asset Group API V3 — Developer Guide

• Applies to: Sprinklr Asset Group API V3 (/api/v3/asset-group)
• V2 API reference: Asset Group | Sprinklr Developer Portal

An asset group is a grouping of entities in Sprinklr. For example, an Account Group is a grouping of multiple accounts created either by individually selecting accounts to add (static) or based on one or more properties (dynamic). Another example is a User Group, which comprises multiple users at the Workspace level. The Asset Group APIs let you perform CRUD operations on these groups programmatically.

Supported asset groups (V2 portal listing): Account Groups, User Groups, Topic Groups, Workspace Groups.

Asset Group V3 exposes full CRUD across two paths, differentiated by HTTP method:

This is the central design change from V2, which used POST /api/v2/asset-group for creation and the same /api/v2/asset-group/{groupId} resource for read, update, and delete. In V3 the paths are identical in shape but sit under /api/v3, return the V3 response envelope, and are backed by formal request/response schemas.

⚠️ Naming asymmetry. The request schema (AssetGroupRequest) uses clientCustomFields and partnerCustomFields. The response schema (AssetGroup) returns the same data as clientCustomProperties and partnerCustomProperties. Do not assume round-trip symmetry when mapping objects in your client code.

An asset group is addressed by its Sprinklr identifier only:

• Path parameter groupId — type String, required, described as "Group id" in the specification. Example from the V3 create response: 6a8d7eebb1f9c0f214fd4011.

There is no fetch-by-name, bulk-fetch, or search operation for asset groups in the V3 specification.

All V3 API calls are sent to:

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

So the asset group resource is:

https://api3.sprinklr.com/{env}/api/v3/asset-group
https://api3.sprinklr.com/{env}/api/v3/asset-group/{groupId}

Replace {env} with your assigned environment identifier. The specification declares the env server variable with default prod and the following enumerated values:

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

See APIs | Sprinklr Developer Portal for the published environment list [doc:turn1doc11].

All Asset Group API calls are authenticated with OAuth 2.0.

Permissions. AssetGroupApiV3 was updated to require MANAGE permission for create and edit. A caller without the required permission receives 403 Forbidden.

Sprinklr's API governance model inherits the calling user's roles and permissions: all permissions tied to a user are equally applied to that user's API key, so a 403 almost always indicates a governance gap rather than a malformed request [doc:turn1doc9].

POST /api/v3/asset-group

Creates an asset group. The response returns the group id and the other related objects.

Endpoint as documented in the V3 source document:

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

Required properties per the specification: name, groupType, assetType.

Required-field conflict. The OpenAPI schema marks only name, groupType, and assetType as required; the V3 source document marks clientId and assetIds as Required, and assetPermissions[].ids / subscribers[].ids as Required, while the schema marks the nested ids as optional. Treat the schema as authoritative for validation and see §10.

curl --location 'https://api3.sprinklr.com/{env}/api/v3/asset-group/' \
--header 'Authorization: Bearer {{accessToken}}' \
--header 'Key: {{apiKey}}' \
--header 'Accept: application/json' \
--header 'Content-Type: application/json' \
--data '{
  "name": "Santhosh Asset Group8",
  "description": "Asset Group created via V3 API",
  "clientId": 66000002,
  "assetIds": [
    "600054962"
  ],
  "groupType": "DEFINED",
  "assetType": "ACCOUNT",
  "assetPermissions": [
    {
      "type": "USER",
      "ids": [
        "600037831"
      ]
    }
  ],
  "subscribers": [
    {
      "type": "USER",
      "ids": [
        "600037831"
      ]
    }
  ]
}'

{
  "data": {
    "id": "6a8d7eebb1f9c0f214fd4011",
    "name": "Santhosh Asset Group8",
    "description": "Asset Group created via V3 API",
    "assetIds": [
      "600054962"
    ],
    "createdTime": 1787657963670,
    "modifiedTime": 1787657963670,
    "ownerUserId": 66015421,
    "spaceId": 66001165,
    "deleted": false,
    "groupType": "DEFINED",
    "assetType": "ACCOUNT",
    "assetPermissions": [
      {
        "type": "USER",
        "ids": [
          "600037831"
        ]
      }
    ],
    "subscribers": [
      {
        "type": "USER",
        "ids": [
          "600037831"
        ]
      }
    ]
  },
  "errors": []
}

Schema-required fields on AssetGroup are id, name, assetType.

PUT /api/v3/asset-group/{groupId}

Updates an existing asset group and returns the updated objects.

Endpoint as documented in the V3 source document:

https://api3.sprinklr.com/{env}/api/v3/asset-group/id={{assetGroupId}}

PUT takes the same AssetGroupRequest schema as POST. The V3 source document lists the following required/optional split for the update body:

curl --location --request PUT 'https://api3.sprinklr.com/{env}/api/v3/asset-group/id={{assetGroupId}}' \
--header 'Authorization: Bearer {{accessToken}}' \
--header 'Key: {{apiKey}}' \
--header 'Content-Type: application/json' \
--data '{
  "name": "Santhosh Asset Group7 Updated",
  "description": "Asset Group updated via V3 API",
  "clientId": 66000002,
  "assetIds": ["600054962"],
  "groupType": "DEFINED",
  "assetType": "ACCOUNT",
  "assetPermissions": [
    {
      "type": "USER",
      "ids": ["600037831"]
    }
  ],
  "subscribers": [
    {
      "type": "USER",
      "ids": ["600037831"]
    }
  ]
}'

204 No Content

PUT sends the full AssetGroupRequest document. There is no PATCH operation for asset groups in V3, so any field you omit from the body is at risk of being cleared. Read the group with GET first, apply your changes to the returned object, and send the complete document back.

DELETE /api/v3/asset-group/{groupId}

Deletes an asset group by group id.

https://api3.sprinklr.com/{env}/api/v3/asset-group/{groupId}

curl --location --request DELETE 'https://api3.sprinklr.com/{env}/api/v3/asset-group/{groupId}' \
--header 'Authorization: Bearer {{accessToken}}' \
--header 'Key: {{apiKey}}' \
--header 'Accept: application/json'

HTTP Status: 204 No Content

GET /api/v3/asset-group/{groupId}

Fetches an asset group's details and all related objects, using the group id.

https://api3.sprinklr.com/{env}/api/v3/asset-group/{groupId}

curl --location 'https://api3.sprinklr.com/{env}/api/v3/asset-group/{groupId}' \
--header 'Authorization: Bearer {{accessToken}}' \
--header 'Key: {{apiKey}}'

{
  "data": [
    {
      "id": "6a8d8262b1f9c0f214fd420f",
      "name": "Santhosh Asset Group9",
      "description": "Asset Group created via V3 API",
      "assetIds": [
        "600054962"
      ],
      "createdTime": 1787658850242,
      "modifiedTime": 1787658850242,
      "ownerUserId": 66015421,
      "spaceId": 66001165,
      "deleted": false,
      "groupType": "DEFINED",
      "assetType": "ACCOUNT"
    }
  ],
  "errors": []
}

Asset Group V3 responses use the standard V3 envelope:

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

The error envelope (ErrorResponse) used by all 4xx responses is:

The four V2 endpoints listed above are the exact set named as the parity scope for V3.

The path shapes are unchanged. The migration work is in the base path, the response envelope, the field names, and the enum surface — not in the routing.

1. Update the base URL. Point at https://api3.sprinklr.com/{env}/api/v3/asset-group.
2. Unwrap the envelope. Read the group from response.data instead of the response root, and tolerate data being an object (POST) or a single-element array (GET).
3. Handle the new error format. Inspect response.errors[] and log errors[].code and errors[].message.
4. Rename read-side custom fields. clientCustomFields → clientCustomProperties, partnerCustomFields → partnerCustomProperties. Leave the request-side names as-is.
5. Remap clientId on read to spaceId.
6. Audit assetType values. Any integration that sends or expects BENCHMARKING_ACCOUNT must be resolved before cutover.
7. Confirm groupType values. V2 documentation says Static/Dynamic; V2 examples use DYNAMIC; V3 examples use DEFINED.
8. Grant MANAGE permission to the API user used for create and update calls.
9. Accept both 200 and 204 as success on PUT and DELETE, and do not assume a JSON body.
10. Read-modify-write on updates. V3 has no PATCH; send the complete document on every PUT.

BENCHMARKING_ACCOUNT, present in the V2 documentation [doc:turn1doc8], is not part of the V3 AssetType enum.

Typed as a plain string in the specification, described as "Type of Group" (request-side description: "Type of group e.g. DEFINED, DYNAMIC"). It is not a closed enum in V3. Values seen in documented examples: DEFINED (V3), DYNAMIC (V2).

Both objects are structurally identical but are separate components in the specification. There is also an unrelated AssetPermission component (holding shareConfigs[] and grants[]) that is not referenced by any asset group operation — do not confuse it with the assetPermissions array on AssetGroup/AssetGroupRequest.

POST /api/v3/asset-group with assetType: "ACCOUNT", groupType: "DEFINED", and the account ids in assetIds[]. Grant access at creation time via assetPermissions[] and notify owners via subscribers[].

There is no incremental-add operation. Call GET /api/v3/asset-group/{groupId}, append the new id to assetIds[] from the returned object, and send the complete document back with PUT.

Where your external system is authoritative, PUT is the correct verb — it replaces the whole document, so removals in the source system propagate. Where it is not authoritative, always read first.

DELETE /api/v3/asset-group/{groupId}. Expect 204 No Content (or 200 per the spec) and no body — do not attempt to parse the response as JSON.

Identifiers

• groupId is a String (24-character hex ObjectId in all documented examples, for example 6a8d8262b1f9c0f214fd420f). Do not coerce it to a number.
• assetIds[], assetPermissions[].ids[], and subscribers[].ids[] are arrays of strings, even when the underlying ids are numeric ("600054962").
• clientId on the request is an integer (int64, for example 66000002), while the corresponding response field spaceId is also a Long. The V3 update document describes clientId as String — the schema types it as an integer.

Updates

• V3 has no PATCH for asset groups. Every update is a full replace.
• Do not rely on the ?id= query parameter shown in the update document; the specification defines only the path parameter.

Enums and casing

• assetType values are uppercase and case-sensitive: USER, BRAND, ACCOUNT, CLIENT.
• type values inside assetPermissions[] and subscribers[] are documented as USER, GLOBAL, CLIENT.

Timestamps

• createdTime and modifiedTime are epoch milliseconds as 64-bit integers (for example 1787657963670). Do not parse them as seconds.

Permissions

• Provision MANAGE for the API user before migrating write traffic; a 403 on V3 where V2 succeeded is the expected symptom of a missing grant.

Error handling

• Always inspect the errors array even on a 2xx response — the envelope carries errors on success responses too (empty in the documented examples).

Credentials

• All tokens and keys in this guide are placeholders ({{accessToken}}, {{apiKey}}). Never commit or log real keys.