Connected Underwriting Life Create Case API Share Share via LinkedIn Reddit Email Copy Link Print On This Page This content applies solely to Connected Underwriting Life, which must be purchased separately from the Appian base platform. This content was written for Appian 23.3 and may not reflect the interfaces or functionality of other Appian versions. Introduction The Create Case API version 1 provides an endpoint for external systems to create a new case in your Connected Underwriting Life Workbench solution. Clients of the API are able to specify data about a case in the body of their requests. Upon successful validation of their request, the caller receives a successful response containing the case ID of the newly created case. The structure of the Create Case API mimics the structure and process of the manual creation of a case, and the same data points and validations are used in the API and the Create a Case wizard. Endpoint The Create Case API has a default endpoint of connected-underwriting-life-case-create. Additionally, you can append the API version to the end of the endpoint. For example, connected-underwriting-life-case-create/v1 indicates a call to the Create Case API version 1. Note that if you do not provide a version path in the endpoint, the CU Life application will use version 1 of the Create Case API by default. Expected Request Structure Headers Clients must send a Content-Type header as application/json. This is standard behavior for Appian API objects. Query Parameters There are no expected query parameters that should be sent in a request to the Create Case API. Body The expected structure of a request body can be seen below: Variable Name Datatype Required productType code Required isExistingCoverage boolean Required existingCarrierName text Conditional proposedEffectiveDate date Required applicationSignedDate date Required coverages list of dictionary Required proposedInsured dictionary Required beneficiaries List of dictionary Required agent dictionary Required payer dictionary Required owners List of dictionary Required occupation dictionary Optional drivingInfo dictionary Optional risk dictionary Optional externalPointers List of dictionary Optional coverage Dictionary Within each coverage dictionary, the following structure is expected: Variable Name Datatype Required coverageIndicator code Required coverageType code Required amount integer Conditional benefits List of dictionary Optional benefitType code Required amount integer Optional benefit Dictionary Within each benefit dictionary contained in a coverage dictionary, the following structure is expected: Variable Name Datatype Required benefitType code Required amount integer Optional proposedInsured Dictionary The following structure is expected in the proposedInsured dictionary: Variable Name Datatype Required firstName text Required lastName text Required suffix text Optional maritalStatus code Optional gender code Optional dateOfBirth date Optional countryOfBirth code Optional citizenship code Required socialSecurityNumber text Conditional immigrationNumber text Conditional addressLine1 text Optional addressLine2 text Optional addressCity text Optional addressState code Optional addressZip text Optional yearsAtAddress integer Optional phoneNumberType code Optional phoneNumber text Optional email text Optional beneficiary Dictionary Within each dictionary in the beneficiaries field, the following structure is expected: Variable Name Datatype Required beneficiaryLevel code Required allocationPercentage integer Required entityType code Required relationshipToInsured code Optional firstName text Conditional lastName text Conditional suffix text Optional dateOfBirth date Optional governmentIdType code Optional governmentId text Optional organizationType code Optional organizationName text Conditional payer Dictionary The following structure is expected in the payer dictionary: Variable Name Datatype Required entityType code Required relationshipToInsured code Optional firstName text Conditional lastName text Conditional suffix text Optional organizationType code Optional organizationName text Conditional owners Dictionary Within each dictionary in the owners field, the following structure is expected: Variable Name Datatype Required entityType code Required relationshipToInsured code Optional firstName text Conditional lastName text Conditional suffix text Optional organizationType code Optional organizationName text Conditional occupation Dictionary The following structure is expected in the occupation dictionary: Variable Name Datatype Required estimatedNetWorth integer Optional estimatedSalary integer Optional occupation text Optional employerName text Optional businessAddressLine1 text Optional businessAddressCity text Optional businessAddressState code Optional businessAddressZip text Optional yearsOfEmployment integer Optional employmentDuties text Optional drivingInfo Dictionary The following structure is expected in the drivingInfo dictionary: Variable Name Datatype Required hasDriversLicense boolean Optional driversLicenseCountry code Optional driversLicenseState code Optional driversLicenseId text Optional driversLicenseExpirationDate date Optional risk Dictionary The following structure is expected in the risk dictionary: Variable Name Datatype Required usesNicotine boolean Optional usesControlledSubstances boolean Optional usesAlcohol boolean Optional weight decimal Optional height decimal Optional isTreatmentRecommended boolean Optional isRecentlyHospitalized boolean Optional medicalConditions List of dictionary Optional criminalHistory List of dictionary Optional plannedHazardousActivities List of code Optional travelInformation List of dictionary Optional medicalCondition Dictionary Within each medicalCondition dictionary, the following structure is expected: Variable Name Datatype Required medicalCondition code Required applicability code Required criminalHistory Dictionary Within each criminalHistory dictionary, the following structure is expected: Variable Name Datatype Required typeOfCharge code Required convictionDate date Required crimeDescription text Required travelInformation Dictionary Within each travelInformation dictionary, the following structure is expected: Variable Name Datatype Required typeOfTravel code Required country code Required externalPointer Dictionary Within each externalPointer dictionary, the following structure is expected: Variable Name Datatype Required typeOfTravel code Required country code Required Code Fields A few of the fields listed above have a code datatype. This means that requests must have a specific value from a predefined list provided for these fields. In the backend, these fields correspond to a specific reference data list. Failure to provide a valid value for any of these fields will result in a 400 error response. A list of codes valid for a particular field can be found in the externalCode column of the corresponding reference data table. As additional pieces of reference data are added, values in this column can be updated so that this API or other APIs can accept the new piece of reference data across the application. Possible Responses A few possible response codes can be sent back to the caller of the Create Case API: Response Code 200 This response code indicates a successful request and creation of a case in Appian. The provided response body will contain the case ID of the newly-created case. Response Code 400 This response indicates the caller sent a bad request. Cases will not be made from requests that return a 400 error response. The response body will provide additional information on why the request was bad. Possible errorCodes contained in the response body include: MISSING_REQUIRED_FIELD: A field that was required in the request body was not present. The field that was missing will be provided. INVALID_CODE: A field that expects a code datatype did not have a valid value. The associated reference data point that had an invalid value will be provided. DATA_INTEGRITY_VIOLATION: Additional validations on the request body were violated. This can include a range of possibilities and mimic any additional validations present in the manual creation of a case. Possible reasons include sending duplicate medicalCondition codes, failing to have coverage with an indicator of Base, or sending an applicationSignedDate that is in the future. DATABASE_LENGTH_VIOLATION: A field provided in the request breached its maximum length allowed in the database. The field or fields that were too long will be provided. Response Code 404 This response code is an Appian default and indicates a problem authenticating. Response Code 500 This response code is an Appian default and indicates there was a backend expression or process error. Feedback Was this page helpful? SHARE FEEDBACK Loading...
