OGS Cases via API and UI
Hello!
I'm looking on ongoing monitoring API, and can't understand some cases on PILOT version.
request:
POST https://api-worldcheck.refinitiv.com/v2/cases/ongoingScreeningUpdates
{
"query": "updateDate>='1980-01-01T00:00:00Z'; (providerType=='WATCHLIST')",
"pagination": {
"currentPage": 1,
"itemsPerPage": 250
},
"sort": [
{
"columnName": "updateDate",
"order": "ASCENDING"
}
]
}
Response:
{
"query": "updateDate>='1980-01-01T00:00:00Z'; (providerType=='WATCHLIST')",
"sort": [
{
"columnName": "updateDate",
"order": "ASCENDING"
}
],
"totalResultCount": 26,
"pagination": {
"currentPage": 1,
"itemsPerPage": 250,
"totalItems": 26
},
"results": [
{
"caseSystemId": "5jb69uigfy7r1i99ggqdgkvmo",
"updateDate": "2023-12-24T04:17:21.986Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb72ggl8ldk1i99g63lf8m2u",
"updateDate": "2023-12-24T08:46:51.798Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb85z1vg5t31i99g3qr3ursx",
"updateDate": "2023-12-24T14:52:08.702Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7cq96pg2s",
"updateDate": "2023-12-28T15:03:45.909Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb7szfj3b8f1i8cgpzneh6py",
"updateDate": "2023-12-29T10:48:29.801Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb6cl602p9o1iafob4zxa98q",
"updateDate": "2023-12-30T05:03:28.907Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb6h8vlzjju1i85edsrzi918",
"updateDate": "2024-01-03T06:00:46.026Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7cq96pg2s",
"updateDate": "2024-01-03T15:15:53.556Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb6h8vlzjju1i85edsrzi918",
"updateDate": "2024-01-04T06:08:49.028Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7cq96pg2s",
"updateDate": "2024-01-04T15:20:23.653Z",
"numberOfNewResults": 3,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb69io9rmjb1i8v40vw4o14r",
"updateDate": "2024-01-07T04:24:41.571Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb7rk4pf6hn1i7o7a5iqf2r2",
"updateDate": "2024-01-07T12:43:45.627Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb7szfj3b8f1i8cgpzneh6py",
"updateDate": "2024-01-07T13:09:12.525Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7cq96pg2s",
"updateDate": "2024-01-07T14:31:54.422Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7c0ls8qc8",
"updateDate": "2024-01-07T14:32:03.974Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb7szfj3b8f1i8cgpzneh6py",
"updateDate": "2024-01-09T13:11:48.139Z",
"numberOfNewResults": 2,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb6h8vlzjju1i85edsrzi918",
"updateDate": "2024-01-10T05:55:54.601Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb6mk9lwv2n1i85edsrzkbkz",
"updateDate": "2024-01-10T06:43:34.990Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb73puatur91iafr1ioe14n8",
"updateDate": "2024-01-10T09:12:46.318Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7cq96pg2s",
"updateDate": "2024-01-10T12:14:03.859Z",
"numberOfNewResults": 2,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb6h8vlzjju1i85edsrzi918",
"updateDate": "2024-01-11T05:48:28.780Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb6mk9lwv2n1i85edsrzkbkz",
"updateDate": "2024-01-11T06:37:01.753Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb7szfj3b8f1i8cgpzneh6py",
"updateDate": "2024-01-11T13:14:51.045Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb81j8bx5zr1i7o7cq96pg2s",
"updateDate": "2024-01-12T17:59:45.665Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
},
{
"caseSystemId": "5jb6h8vlzjju1i85edsrzi918",
"updateDate": "2024-01-15T01:42:47.322Z",
"numberOfNewResults": 0,
"numberOfUpdatedResults": 1
},
{
"caseSystemId": "5jb7szfj3b8f1i8cgpzneh6py",
"updateDate": "2024-01-16T14:46:35.287Z",
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
}
]
}
In response I found cases which I didn't find in UI. For example caseId's:
5jb69uigfy7r1i99ggqdgkvmo, 5jb72ggl8ldk1i99g63lf8m2u
And I found caseId in UI, which I didn't find in response:
5jb783or6elt1i8cgpzneh3wv
Can you help me with this cases? On production everything is ok.
Best Answer
-
Hi @kbelyaev ,
Thanks for reaching out to us!
It's not right way to compare the case results which are able to see in your WC1 UI case manager with the response which you are getting from the ongoingScreeningUpdates endpoint.
- When you initiate the endpoint SEQ-case-monitor-ogs: Monitor ongoing screening updates on cases to fetch the ongoing screening updates on cases, if any case has multiple ongoing screening updates you will be able to find multiple update dates of the same caseSystemId in the API response.
Note: Please look at the API response you have pasted above which contains caseStstemId's having multiple OGS updates.
Moreover, to achieve your use case you can utilize the endpoint [SEQ-case-search]: Search for Cases based on specified criteria from our latest postman collection which similarly works as the Case Manager in UI (Please access the following link LSEG World-Check One API to more understand about the caseSearch endpoint)
Thanks
0
Answers
-
The answer seems to be completely irrelevant to original question.
There's no problem with having multiple entries for same caseSystemId in a response. The problem is that the response contains caseSystemIds, that do return 404 when tried via https://api-worldcheck.refinitiv.com/v2/cases/{
{case-system-id}} endpoint. And, what's most important, also response does not contain some caseSystemIds of cases that do have updates.0 -
The answer seems to be completely irrelevant to original question.
There's no problem with having multiple entries for same caseSystemId in a response. The problem is that the response contains caseSystemIds, that do return 404 when tried via https://api-worldcheck.refinitiv.com/v2/cases/{ {case-system-id}}?aggregatedSummary=true endpoint. And, what's most important, also response does not contain some caseSystemIds of cases that do have updates.
0 -
Hi @akrivosheya,
- The reason you are getting 404 responses for those caseSystemId when you tried via https://api-worldcheck.refinitiv.com/v2/cases/{ {case-system-id}}?aggregatedSummary=true is that the cases have already been deleted.
- One more thing I observed as you are using caseSystemId to search the case in UI you are unable to see those case details. (you can only search for the case in UI using caseId)
1 -
That's a possibility, as it is pilot cases get deleted periodically, probably those with ongoing monittoring too. But there's still cases missing from response.
For example, in UI I can see that case (caseId 5jb6mk9lwv2n1i892yugnbawv, caseSystemId 5jb6mk9lwv2n1i892yugnbaww) has OGS update from Dec 5th though there's no entry in response from /v2/cases/ongoingScreeningUpdates corresponding to it. Same for another case (caseId 5jb7kljsux0n1i8ghuboiu544, caseSystemId 5jb7kljsux0n1i8ghuboiu545) with OGS update from Dec 8th. And so on.
0 -
Hi @akrivosheya ,
With whatever date range you are querying the ongoingScreeningUpdates, OGS updates are available only for 30 days from the date when OGS notification is received. OGS updates which are older than 30 days are not available for retrieval via ongoingScreeningUpdates. For example, if the OGS notification was received on 14-Dec-2023, then the respective OGS updates can be accessed only until 13-Jan-2024.
The above statement is the reason which is why you are able to see those details via UI and not able to find those details over the response of ongoingScreeningUpdates endpoint.
Hope this clarifies.
1 -
Thank you, that's what I was suspecting. Documentation https://developers.lseg.com/content/dam/devportal/en_us/product-docs/wc1-api/documentation/v2/schema-reference/wc1-api-schema-reference-documentation.html#tag/case/operation/getOngoingScreeningUpdates is not mentioning this.
0
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛