This document describes the Claim Page API. This API can be used to get all the data that is accessible from the Claim Page.
Claim Page API can divided into three parts:
In order to send data to Claim Page endpoints the access_token is required. This token can be obtained from the Authentication Endpoint. Please refer to the documentation about details of authentication process.
API caller should request platform-case:read
from Authentication Endpoint.
Token should be then used in a cookie: claim-page-cookie
.
There are two more cookies that can be set:
claim-page-language
– example value: en
. If this isn't set, CP will use value from Accept-Language
headercontextUserGlobalId
– this is a GUID of another CWA user. Setting this value means, that CP will be accessed in impersonation mode.Claim Page can be accessed in one of the two modes:
The second mode means, that claim handler logs into application in scope of claimant and he sees what claimant would see in first mode. However, claim handler can only use application in read mode, which means that he cannot perform any actions. For this reason, some of API calls are validated against impersonation and cannot be invoked as claim handler.
Claim Page API is integrated with following APIs:
Endpoint | Method | Integration flow | Impersonation |
---|---|---|---|
/api/appInfo/app-info | GET | CP | Both |
/api/app-settings | GET | CP | Both |
/api/claims/{claimId}/attachment | POST | CP -> CWA | Only false |
/api/claims/{claimId}/attachment | DELETE | CP -> CWA | Only false |
/api/claims/{claimId}/audit/pageVisited | POST | CP -> CWA, then back to CP -> BI | Both |
/api/claims | GET | CP -> CWA | Both |
/api/companies | GET | CP -> CWA | Both |
/api/claims/{claimId}/contacts | GET | CP -> CWA | Both |
/api/contacts/{contactId} | POST | CP -> CWA | Only false |
/api/claims/{claimId}/contacts/mobilePhonePrefixes | GET | CP -> CWA | Both |
/api/claims/{claimId}/craftsman-invitation | POST | CP -> CWA | Only false |
/api/claims/{claimId}/details/faq | GET | CP -> CWA, then back to CP -> CD | Both |
/api/claims/{claimId}/details/information | GET | CP -> CWA | Both |
/api/claims/{claimId}/details/links | GET | CP -> CWA, then back to CP -> CD | Both |
/api/claims/{claimId}/externalUrls/shop | GET | CP -> CWA | Both |
/api/claims/{claimId}/externalUrls/selfService | GET | CP -> CWA | Both |
/api/claims/{claimId}/features | GET | CP -> CWA | Both |
/api/claims/{claimId}/files/files | GET | CP -> CWA | Both |
/api/claims/{claimId}/files/documents | GET | CP -> CWA | Both |
/api/claims/{claimId}/files/files/viewed | PUT | CP -> CWA | Both |
/api/claims/{claimId}/files/download | GET | CP -> CWA | Both |
/api/claims/{claimId}/financial-overview | GET | CP -> CWA | Both |
/api/claims/{claimId}/footer | GET | CP -> CWA, then back to CP -> CD | Both |
/api/claims/{claimId}/history | GET | CP -> CWA | Both |
/api/claims/{claimId}/history | PUT | CP -> CWA | Both |
/api/images/{attachmentInfoId}/thumbnail | GET | CP -> CWA | Both |
/api/images/{attachmentInfoId}/preview | GET | CP -> CWA | Both |
/api/claims/{claimId}/messages | POST | CP -> CWA | Only false |
/api/claims/{claimId}/services | GET | CP -> CWA | Both |
/api/claims/{claimId}/state | GET | CP -> CWA | Both |
/api/claims/{claimId}/state/description | GET | CP -> CWA, then back to CP -> CD | Both |
/api/claims/{claimId}/updates/trigger | GET | CP -> CP UI | Both |
/api/user/logged-user-info | GET | CP | Both |
As a rule, if CP needs to call CD for templates, it makes two calls to CWA:
When a call to BI is made, CP is calling CWA for user's role.
Whenever case's messages or files are changed (added new or modified) from outside of CP, the /api/claims/{claimId}/updates/trigger
call is made from external application to refresh the data on UI using SignalR.