List of APIs in Cloud API

Cloud API for ClaimCenter consists of the following APIs:

API Name Description Path
Admin API for administration objects, such as users and groups /admin/v1
API List API for listing the available APIs /apis
Async API for retrieving responses to asynchronously processed calls /async/v1
Claim API for claims and claim-specific objects /claim/v1
Common API for common InsuranceSuite platform objects, such as activities and notes /common/v1
Composite API for composite requests /composite/v1
System Tools API for batch processes and database consistency checks /systemtools/v1
Test Util

API for testing during development

(Available only when enabled)

 /test-util/v1
Note: The /apis endpoint returns all REST APIs for ClaimCenter. This includes some APIs that are not part of Cloud API, such as /system/v0/database and /system/v0/maintenance. The only APIs that are part of Cloud API are the ones listed in the previous table. These are the only APIs that have access to Cloud API features, such as request inclusion and authentication.

Cloud API for ContactManager consists of the following APIs:

API Name Description Path
Admin API for administration objects, such as users and groups /admin/v1
API List API for listing the available APIs /apis
Async API for retrieving responses to asynchronously processed calls /async/v1
Common API for common InsuranceSuite platform objects, such as activities and notes /common/v1
Contact API for contacts /contact/v1
Note: The /apis endpoint returns all REST APIs for ContactManager. This includes some APIs that are not part of Cloud API, such as /system/v0/database and /system/v0/maintenance. The only APIs that are part of Cloud API are the ones listed in the previous table. These are the only APIs that have access to Cloud API features, such as request inclusion and authentication.

You can use the API path to view metadata about the API. This is discussed in detail in the following section.

Version numbers for major and minor releases

The following section defines what a minor release is. Minor releases are not expected to have "breaking changes". The types of changes that do and do not fall into the definition of "breaking change" are described in the Schema Backwards Compatibility Contract. To access a copy of this contract, consult Guidewire.

Release numbers

Every release of Cloud API has a three-digit version number. The first digit is the version's major release number. The second digit is the version's minor release number. For example, suppose the latest release of Cloud API has a version number of 1.5.0. This release is major release 1 and minor release 5.

The release number can be seen in the API definition. For example, in Swagger UI, when you view an API, the version number appears in a gray bubble next to the API name. (Note that individual APIs do not have distinct version numbers. The version numbers that appear in the API definition are for the entire Cloud API release.)

For every API, the major release number is also part of the endpoint path. It is the number that appears after the "/v". For example, the first major release of the Admin API has a path of /admin/v1. If there was a theoretical ninth major release of the Admin API, its path would be /admin/v9.

Minor and major releases

In future releases, Cloud API functionality is expected to change. To define and control these changes, Guidewire defines the scope of change that can be added to each release.

  • In a minor version release, the functionality is either identical to the previous release or additive.
  • In a major version release, the functionality has changed from the previous release.

A given release of ClaimCenter can have multiple major versions of Cloud API. For example, suppose that in a given year there were the following releases:

  • The January release is the first new major release.
  • The April release is solely additive to the previous release.
  • The July release is solely additive to the previous release.
  • The October release includes changes to existing functionality.

In this case, the January, April, and July releases would all include a single major release of the APIs whose endpoint included "/v1". The October release would include two major versions: the "/v1" major release (whose changes were identical or additive to the previous release) and a new "/v2" major release. This is summarized in the following table.

Release Month Version # Compared to the previous release, this release... Major versions in this release
January 1.​0.​0 ...​is identical or additive /admin/v1
April 1.​1.​0 ...​is identical or additive /admin/v1
July 1.​2.​0 ...​is identical or additive /admin/v1
October 1.​3.​0 and 2.​0.​0 ...​includes changes to existing functionality

/admin/v1 (identical or additive to July's release), and /admin/v2 (containing the changed functionality)