List of APIs in Cloud API
Cloud API for PolicyCenter consists of the following APIs:
API Name | Description | Path |
---|---|---|
Account | API for accounts and account-specific objects | /account/v1 |
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 |
Composite | API for composite requests | /composite/v1 |
Graph | API for operating on entire graphs of objects | /graph/v1 |
Job | API for jobs and job-specific objects | /job/v1 |
Policy | API for policies and policy-specific objects | /policy/v1 |
Product Definition | API for PolicyCenter product definition metadata |
/productdefinition/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 |
/apis
endpoint returns all REST APIs for PolicyCenter. 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 |
/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 PolicyCenter 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 |
|