Migrating From V2 Alpha

This page is intended for customers who are currently using the V2 Alpha version of the Cloud Support API and would like to migrate to V2 Beta.

Getting started with V2 Beta

If you are already using V2 Alpha then you don't need to do any additional setup to start using V2 Beta. You can use the same service accounts/credentials and the API will already be enabled for you.

To call the V2 Beta endpoints, simply replace the /v2alpha/ portion of the request URL to /v2beta/. For example here's how you would upgrade a cases.get call from V2 Alpha to V2 Beta:

V2 Alpha: GET https://cloudsupport.googleapis.com/v2alpha/projects/123/cases/abc

V2 Beta: GET https://cloudsupport.googleapis.com/v2beta/projects/123/cases/abc

Breaking Changes to Case Classifications

Important: This is the only breaking change between V2 Alpha and V2 Beta. Any endpoints that are not mentioned in this section can safely be migrated to V2 Beta without any changes to the business logic or the request/response format.

The only behavior that has changed from V2 Alpha to V2 Beta is the Case Classification type.

V2 Alpha CaseClassification

Field	Required for case creation	Description
productType	Yes	string The product type the classification corresponds to.
value	Yes	string The classification to be used when creating a case, e.g. "Technical Issue > Compute > Compute Engine"

V2 Beta CaseClassification

Field	Required for case creation	Description
id	Yes	string The unique ID for a classification. Must be specified for case creation.
displayName	No	string The display name of the classification.

Why did we make these changes?

• Removing the productType field

  • An early design of the API required us to add this field but as the API evolved it became obsolete.
  • This field is required but the only valid value is GOOGLE_CLOUD. That adds boilerplate to every case creation request.

• Separating value into id and displayName

  • The value field in V2 Alpha must be human readable (so that a human can choose from the list of options) and machine readable (so that our API can tell what type of case is being created).
  • V2 Beta separates these concerns into two fields. id is the machine readable part of the classification, displayName is the human readable part.
  • This gives us the flexibility to make changes to the display name without breaking API integrations. For example, we may want to have multiple translations of the displayName in the future but the id would stay the same for all translations since they represent the same case classification.