The base configuration system APIs
The base configuration includes the following system APIs:
|Claim||API for claims and claim-specific objects||
|Admin||API for administration objects||
API for testing during development
(Available only when ClaimCenter is started in the
|Common||API for common InsuranceSuite platform objects like activities and notes||
|API List||Dynamically lists the APIs that are available||
You can use the API path to view metadata about the API. This is discussed in detail in the following section.
There are also a minimal set of APIs for ContactManager. For more information, refer to the
<appURL>/rest/apis endpoint for ContactManager.
Cloud API versions
Every version of Cloud API has a version number. For example, suppose that there were four releases of the system APIs in January, April, July, and October of a given year. Each release could have the following version numbers:
- January: 1.0.0
- April: 1.1.0
- July: 1.2.0
- October: 2.0.0
Minor and major releases
In future releases, system API functionality is expected to change. To define and control these changes, the Cloud API makes use of minor versions and major versions.
- A minor version is a version of the Cloud API in which functionality is either identical to the previous release or additive.
- A major version is a version of the Cloud API in which functionality has changed from the previous release.
A given release of the Cloud API can have multiple versions of the APIs, some of which are minor and some of which are major.
Major versions are indicated by the "endpoint path number" in API endpoint paths. This is the
number that appears after the "
/v". (For example, in
/common/v1/activities, the endpoint path number is 1.) When Guidewire
makes a change to an API that is not purely additive, the changed API is considered a major
release. Its endpoint number is incremented by 1.
When a release of the Cloud API includes a new major release, the previous minor release is also included. The minor release may be identical to the previous release, but it may also have additive changes.
For example, suppose that for the releases from the previous example:
- The Cloud API in the January release is major version 1.
- The Cloud API in the April release is identical or additive.
- The Cloud API in the July release is identical or additive.
- The Cloud API in the October release includes changes to existing functionality.
In this case, the January, April, and July releases would all include a single version of the APIs whose endpoint included "/v1". The October release would both the "/v1" set of APIs and a new "/v2" set of APIs. 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||/common/v1|
|April||1.0.1||...is identical or additive||/common/v1|
|July||1.0.2||...is identical or additive||/common/v1|
|October||2.0.0||...includes changes to existing functionality||
/common/v1 (identical or additive to July's release) and
/common/v2 (containing the changed functionality)