SailPoint CLI `transform preview` returns 400.1 Bad request content in Sandbox only

Hello,

The SailPoint CLI transform preview command returns a 400.1 Bad request content error when it is executed against our Identity Security Cloud Sandbox tenant.

The preview previously worked in the Sandbox tenant. The same command and transform definition still work successfully against our Production tenant.

Environment

  • Product: Identity Security Cloud
  • SailPoint CLI version: 2.2.10
  • Affected environment: Sandbox
  • Production environment: Working as expected
  • Previously working in Sandbox: Yes
  • Recent configuration changes: None that we are aware of

What we tried

We executed the following command from PowerShell:

sail transform preview `

  --file "C:\transform\20260713\create_transform_mail.json" `

  --env <sandbox-environment-name>

The transform file contains the following JSON:

{

  "name": "mail",

  "type": "identityAttribute",

  "attributes": {

    "name": "email"

  }

}

We also executed the same preview against our Production tenant. It works successfully in Production, but consistently fails in Sandbox.

Actual result

The command returns the following error:

Error:

Issues calling API

Response body:

{

  "causes": [],

  "detailCode": "400.1 Bad request content",

  "messages": [

    {

      "locale": "en-US",

      "localeOrigin": "DEFAULT",

      "text": "The request was syntactically correct but its content is semantically invalid."

    },

    {

      "locale": "und",

      "localeOrigin": "REQUEST",

      "text": "The request was syntactically correct but its content is semantically invalid."

    }

  ],

  "trackingId": "dcfe100114a742278fef70472672790f"

}

The response headers also include:

X-Sailpoint-Route-Version: beta

Expected result

We expect the CLI to evaluate the transform and return the preview result, as it previously did in Sandbox and still does in Production.

Additional information

  • The Transform Preview feature had been working in Sandbox for several months.
  • We are not aware of any tenant or CLI configuration changes made immediately before the issue started.
  • Before the issue occurred, the CLI command was interrupted several times using Ctrl+C.
  • There is currently no known workaround.
  • The issue is reproducible in Sandbox.
  • Production is not affected.

Questions

  1. What conditions can cause the Transform Preview API to return 400.1 Bad request content when the JSON itself is syntactically valid?
  2. Could this be caused by tenant-specific Transform Preview state or a service-side issue in the Sandbox tenant?
  3. Does the CLI maintain any local cache or temporary state that should be cleared?
  4. Could interrupting preview commands with Ctrl+C leave any local or server-side preview state that needs to be reset?
  5. Is there a debug or verbose option that can show the actual request body sent by the CLI or provide more details about which content is considered semantically invalid?
  6. Has anyone encountered this error in only one tenant while the same command works in another tenant?

Any guidance on additional troubleshooting steps would be appreciated.

Thank you.

Since the issue occurs in sandbox tenant, the CLI itself is not the problem. The 400 error means the tenant rejected the temporary transform rather than the CLI request itself.

Check:

  • Verify that the identity, identity profile, sources, and any referenced transforms exist in that tenant.
  • confirm your PAT has transform create/delete permissions.
  • Run the command with debug logging and capture the full error response and trackingId.
  • test " sail transform create -f <transform.json> "in the sandbox.

If the same transform previews successfully in another tenant but consistently fails only in this Sandbox, it is likely a tenant-specific backend issue.

Share the trackingId with the SailPoint support to identify the root cause.

Hello Soshiro. The Ctrl+C interruptions may have left temporary preview objects behind in Sandbox.

transform preview creates a temporary <transform-name>-preview transform and an identity attribute named sailpointCLIPreview, then removes them after the preview. The SailPoint CLI maintainer has confirmed that this cleanup can sometimes fail and cause the same 400.1 error. Please check:

GET /v2025/identity-attributes/sailpointCLIPreview

If it exists, delete it:

DELETE /v2025/identity-attributes/sailpointCLIPreview

Then retry the preview. I would also run sail transform list and check whether mail-preview was left behind in Sandbox. If it is there, delete it using its transform ID. Since these objects are stored in the tenant, this would also explain why the same CLI and transform still work in Production.

@hanaie,

@punna0001 is correct, the CLI does it’s best to cleanup the resources it created, even on failures. There are some edge cases that cause these temporary values to stick around.

If you check and find that these values are properly cleaned up and you’re still getting the error, we can dive in deeper!

Thank you all very much for your helpful responses. The issue has now been resolved.

As Harish suggested, we checked the following endpoint in the Sandbox tenant:

GET /v2025/identity-attributes/sailpointCLIPreview

The temporary identity attribute `sailpointCLIPreview` was still present in the Sandbox tenant. After deleting it, the `sail transform preview` command started working normally again.

The temporary `mail-preview` transform had already been removed, but the `sailpointCLIPreview` identity attribute remained. Based on the behavior we observed, it appears that interrupting the preview process with Ctrl+C prevented the CLI from completing the cleanup of this temporary resource.

Harish, your detailed explanation of the temporary resources created by `transform preview`, including the exact endpoint to check, directly led us to the solution. Thank you very much.

Bharani, thank you as well for the initial troubleshooting guidance and for helping us narrow the issue down to the Sandbox tenant rather than the CLI itself.

Tyler, thank you for confirming that temporary resources can remain in certa

in edge cases and for offering to investigate further if the cleanup was not the cause.

For anyone who encounters the same `400.1 Bad request content` error after interrupting a preview, we recommend checking for both of the following temporary resources:

- The `sailpointCLIPreview` identity attribute

- The `-preview` transform

Thank you again to everyone for your support!