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

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 classication 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 classication. 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.