ZEP Indonesia Web Portal API
Overview
Our APIs provides the capabilities for users to get different plans based on product, buy and manage policies across range of products. Our APIs are JSON based which is easily understandable and the heart of our API's are designed to integrate your partnership with us across all of our global entities.
Create Offers
URL: /travel/offers
This API will provide functionality to get offers.
GET policy
URL: /travel/policy/{policyNumber}
This API will provide functionality to get Policy details.
Payment verify
URL: /travel/policy/{policyNumber}/payment/verify
This API will provide functionality to check payment verification.
Payment
URL: /travel/policy/payment
This API will provide functionality to send payment request.
Cancel policy
URL: /travel/policy/cancel
This API will provide functionality to Cancel Policy.
Policy issuance
URL: /travel/policy/issuance
This API will provide functionality to issue the Policy.
Payment
URL: /travel/policy/payment
This API will provide functionality to send payment request.
Endorsement ( Alteration- no Refund )
URL: /travel/policy/{policyId}/endorsement
This API will provide functionality of Alter policy request before start of effective date with no payment/refund.
refund ( Alteration- Refund )
URL: /travel/policy/{policyId}/refund
This API will provide functionality of Alter policy request before start of effective date with refund.
payment ( Alteration- payment )
URL: /travel/policy/{policyId}/payment
This API will provide functionality of Alter policy request before start of effective date with payment.
GET Policy Details
URL: /travel/policy/{policyId}/details
This API will provide functionality to get Policy Details.
Quote Save
URL: /quote/save
This API will provide functionality to create Save Quote .
customer creation
URL: /customer
This API will provide functionality to get account details in azure b2c.
customer creation
URL: /customer/register
This API will provide functionality to create account in azure b2c.
customer black Listed
URL: /customer/blacklist/status
This API will provide functionality to get status of black listed user.
Policy Details
URL: /policy/{policyId}
This API will provide functionality to get policy details of given policyid.
Cancel policy
URL: /policy/cancel
This API will provide functionality to Cancel Policy.
Policy issuance
URL: /policy/issuance
This API will provide functionality to issue the Policy.
Payment
URL: /policy/payment
This API will provide functionality to send payment request.
Endorsement ( Alteration- no Refund )
URL: /policy/{policyId}/endorsement
This API will provide functionality of Alter policy request before start of effective date with no payment/refund.
refund ( Alteration- Refund )
URL: /policy/{policyId}/refund
This API will provide functionality of Alter policy request before start of effective date with refund.
payment ( Alteration- payment )
URL: /policy/{policyId}/payment
This API will provide functionality of Alter policy request before start of effective date with payment.
Download Document
URL: /document/download
This API will provide functionality to download documents from INSIS.
Upload Document
URL: /document/upload/temp
This API will provide functionality to upload documents to AWS S3.
Claims List
URL: /claims/{personId}/list
This API will provide functionality to Retrieve List of Claims by PersonId.
Claims Status
URL: /{claimId}/status-timeline
This API will provide functionality to Retrieve Claim Statuses by claimId.
FNOL
URL: /claims/fnol
This API will provide functionality to post a claim.
Claims Details
_URL: /claims/{claimId}
This API will provide functionality to get a claim.
The Partner Experience API accepts HTTPS/TLS connections only in order to protect the integrity and confidentiality of any data transferred. HTTP connections are refused - plaintext communication is not supported.
As a further means to secure requests, this API will use the following security measures:
Client ID/Secret using Basic Authentication Header
Follow the pre-requisites steps found on the Home Page to gain access.
Once you have access to the client_id and client_secret, pass the values in the Authorization header with the type Basic to make requests on behalf of a user:
Basic client_id:client_secret
The client_id:client_secret value must be a base64-encoded string.
In case of an invalid token, a 401 HTTP Status Code with code authentication_error will be returned.
IP Restriction
IP Range needs to be provided to be restricted at MuleSoft end
This API uses conventional HTTP response codes to indicate the success or failure of an API request.
In general: Codes in the 2xx range indicate success. Codes in the 4xx range indicate an error that failed given the information provided (e.g., a required field was omitted). Codes in the 5xx range indicate an error with the server.
Error HTTP Status Code Summary
| Status Code | Description |
|---|---|
| 400 Bad Request | The server could not understand the request due to invalid syntax |
| 401 Unauthorized | Invalid token. The server was unable to authenticate the user. |
| 404 Not Found | The server was unable to find the requested endpoint. |
| 405 Method not allowed | The server was unable to handle the request due to an invalid method. |
| 415 Unsupported Media Type | The media format of the requested data is not supported by the server. |
| 500 Internal Server Error | An internal server error was observed. |
| 502 Bad Gateway | The server encountered received an invalid response from an inbound server it accessed while attempting to fulfil the request. |
| 503 Service Unavailable | The server was unable to handle the request due to a temporary overloading or maintenance of the server. |
Please refer to each individual resource and method endpoint definition for specific details on the possible status codes returned.
Error Response
Attributes
| Field Name | Description |
|---|---|
| code | Pattern based scheme that identifies a specific and unique error condition. Typically human readable but more suited for machine processing. |
| message | Human readable description of the error that occurred that is not intended to be machine parseable. |
| correlationId | Provide ability to rapidly identify and trace distributed request processing. |
| source | Optional. Describes the source of the error; used to indicate the error originated elsewhere or self-reference when error was generated internally or in direct consequence of downstream events. |
| source/name | Implementation provider defined name for the API, service or system. |
| source/layer | Implementation provider defined name for the API, service or system. |
| causes | Optional. Describes the source of the error; used to indicate the error originated elsewhere or self-reference when error was generated internally or in direct consequence of downstream events. |
| causes/code | Optional. Pattern based string that identifies a more fine grained error condition, which contributed to the general/parent error code above. |
| causes/message | Mandatory. More specific information on the failure cause. |
| causes/field | Optional. A JSON Pointer (RFC6901) that identifies the entity or entity attribute responsible for the more specific error code and message. |
| causes/source | Optional. See “source” object definition above |
Error Response Payload Examples
{
"code": "E10002",
"message": "Unable to process request - Please contact support team",
"correlationId": "f890a9b4-48ed-489e-b627-4692f14ad6cd"
}
{
"code": "invalid_enum",
"message": "Invalid enum value provided.",
"correlationId": "8fa98350-5580-11ee-b30b-02c456ad1aea",
"causes": [
{
"message": "/product/insuredType INDIVIDUAL1 is not a valid enum value"
}
]
}The DDC is committed to continuously improving and expanding the developer experience provided to consumers of this template for Mule API/integration applications. The lifecycle of this template asset is managed using Semantic Versioning.
Where possible, the DDC team will make changes to the API but not change the version number because the changes are not considered to be backward compatible. Such changes can be any of the following:
- Addition of new resources
- Addition of new non-mandatory request parameters of attributes
- Addition of new data fields returned in the response
- Change in the order of data fields returned by the API
There might be some instances in which breaking enhancements need to happen. In such circumstances, a new version is released not to break compatibility. Such enhancements include:
- Inclusion or removal of mandatory parameters
- Restructuring of the API interface
Upon the release of a new version, applications can continue using the old version, allowing the consumer to assess the changes needed. Release notes with all the changes will be provided with every new version, describing all the changes in detail.
Upon upgrading, consumers are required to request access to the new major version of the API. Given the potential breaking changes, consumers are encouraged to perform regression testing against the new version before upgrading to the new API version in production.
The DDC is committed to continuously improving and expanding the developer experience provided to consumers of this template for Mule API/integration applications. The lifecycle of this template asset is managed using Semantic Versioning.Where possible, the DDC team will make changes to the API but not change the version number because the changes are not considered to be backward compatible. Such changes can be any of the following:
- Addition of new resources
- Addition of new non-mandatory request parameters of attributes
- Addition of new data fields returned in the response
- Change in the order of data fields returned by the API
There might be some instances in which breaking enhancements need to happen. In such circumstances, a new version is released not to break compatibility. Such enhancements include:
- Inclusion or removal of mandatory parameters
- Restructuring of the API interface
Upon the release of a new version, applications can continue using the old version, allowing the consumer to assess the changes needed. Release notes with all the changes will be provided with every new version, describing all the changes in detail.
Upon upgrading, consumers are required to request access to the new major version of the API. Given the potential breaking changes, consumers are encouraged to perform regression testing against the new version before upgrading to the new API version in production.