Breaking Changes

Breaking changes are those that will cause disruptions to your Fullstory Server API client applications unless you modify your code to accommodate the change. Should a new API feature result in a breaking change, a new major version for the API will be published that you can opt-in to.

For example, if a client is currently using POST /v2/users and Fullstory decides to make an update to this endpoint that results in a breaking change, a new v3 API will be published and the breaking change will be manifested in POST /v3/users.

Changes that require an API major version upgrade

• Removing or renaming a parameter, request field, or response field
• Removing or renaming a resource URI or method
• Changing existing permission definitions and/or authorization
• Adding a required parameter or request field without default values
• Changing the intended functionality of an endpoint. For example, if a DELETE request previously used to soft delete a resource but now hard deletes the resource.
• Introducing new validation rules
• Changing request or response field types (for example, a response field is changed from an object type to an array type)
• Applying more restrictive rate limiting
• Fixing an HTTP response code from an incorrect code to the correct code

Changes that don't require an API major version upgrade

• Adding new API resources/endpoints.
• Adding new methods to existing endpoints
• Adding new fields in the following scenarios:
  • New fields in responses
  • New optional request fields or parameters
  • New required request fields that have default values
• Changing the order of fields in existing API responses
• Changing the length or format of opaque strings, such as resource IDs
• Changing the value of error messages and other human-readable strings
• Adding an optional request header
• Removal of a redundant request header
• Changing the length of data returned within a field
• Changing the overall response size
• Adding a new value returned for an existing enumerated field