Which change could CyberArk make to the REST API that could cause existing scripts to fail?

Removing parameters from a REST API is a breaking change. Existing scripts and applications are coded to interact with the API based on its defined contract, which includes specific parameters in the request. If a parameter that a script sends is removed from the API, the API endpoint will no longer recognize it. This will likely cause the API to return an error (e.g., a 400 Bad Request status code) because the request is malformed according to the new API definition, thus causing the script to fail. This fundamentally alters the expected input and breaks the established contract with the client.

A. adding optional parameters in the request: This is a non-breaking, backward-compatible change. Existing scripts will continue to function as they are not required to send the new optional parameter.

B. adding additional REST methods: This is an additive change that does not affect existing API methods. Scripts calling the old methods will be completely unaffected by the presence of new ones.

D. returning additional values in the response: This is generally a non-breaking change. Well-designed scripts parse the response for the specific data they need and will simply ignore any new, unexpected fields.

1. CyberArk Privileged Access Manager Documentation 13.2

REST APIs

"Add Account": The documentation for this endpoint specifies a list of required and optional parameters in the request body (e.g.

accountName

address

platformId

secret). If CyberArk were to remove one of these parameters

any existing script built to provide it would be sending a request that no longer conforms to the API's contract

leading to failure. This illustrates that parameters are a fixed part of the API's contract

and their removal would break clients built on that contract.

2. CyberArk Privileged Access Manager Documentation 13.2

What's New

"REST APIs": This section frequently announces the deprecation of APIs or their parameters

stating they "will be removed in a future version." This practice of formal deprecation before removal underscores that removal is a significant

breaking change that developers must prepare their scripts for

confirming that such a change is expected to cause failures in existing integrations.