The InsuranceSuite Cloud API

The InsuranceSuite Cloud API is a set of RESTful system APIs that caller applications can use to request data from or initiate action within an InsuranceSuite application. These APIs provide content for the REST API framework that is present in all InsuranceSuite applications. The APIs are built using the Swagger 2.0 Specification. These are also referred to as the system APIs.

The system APIs can be used by browser-based applications and service-to-service applications. This documentation uses the term caller application to generically refer to any application or service calling a system API.

Making system API calls

The following diagram provides a high-level overview of the interaction between the caller application and the system APIs.

Flow of request to and response from the system APIs
  1. The caller application constructs a request object. The request object consists of:
    • A header, which can contain authentication information and other metadata.
    • A payload, when necessary.
  2. The caller application sends the request to the system API using an HTTP command.
    • The command calls a specific API endpoint.
    • The command may include query parameters that further identify the data that is desired.
    • The request object is sent with the command.
  3. The system API processes the request.
    • This activity uses all of the InsuranceSuite application logic, such as validation logic and pre-update rules.
    • The request is restricted by authorization controls within the system APIs.
  4. The system API responds with an HTTP response code (such as 200 for success) and a response object. The response object consists of:
    • A header
    • A payload, when necessary.

System APIs and InsuranceSuite logic

In the software industry, some RESTful APIs are configured to interact directly with the database. The system APIs are not configured to behave this way. The system APIs interact with operational data only through the layer of the application's business logic. Therefore, the system APIs always leverage the existing business logic of the application.

For example:

  • Suppose an internal user does not have permission to create an activity. If the internal user attempts to create an activity through the system APIs, the attempt results in an insufficient permissions error.
  • Suppose there is a validation rule that requires an activity's due date to be set in the future. If an external system attempts to create an activity with a due date in the past, the attempt results in a validation error.
  • Suppose there is a pre-update rule that creates an approval activity whenever a document is marked as "Final". If an external system creates a "Final" document through a system API, the pre-update rule will create an approval activity.