Patch case by caseSystemId vs Request full screening for an existing case
In the documentation we can see that it is possible to use the endpoint to do a partial update given a caseSystemId, this endpoint allows us to send an empty body and the parameter screen=SYNC, which will execute a re-screning synchronously without doing a updating the fields. The result of this endpoint is similar to using the endpoint to create a new case.
We also have the option of using the endpoint to run a full or delta screening for an existing case, using the screeningMode parameter with the values FULL_SYNC and DELTA_SYNC. The documentation mentions that delta screening performs the screening from the last screening date and shows the new results that appeared after the last screening.
Questions:
- Should the data used on both endpoints be caseSystemId and not caseId?
- On neither endpoint would we be creating a new case, just doing a re-screening, is that correct?
- In the case of using the endpoint for patching, is a delta or full screening executed?
- Does using full/delta screening involve an additional cost?
- Patch endpoint: 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/partialUpdateCase
- Request full or delta screening endpoint: 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/screenCase
Best Answer
-
@tonatiuh.flores - Thank you for your patience.
- Right - the data used on both endpoints should use caseSystemId and not caseId
- Exactly. You are not creating a new case for either endpoints; the PATCH endpoint updates a case while the POST endpoint re-screens an existing case (it's following the asynchronous approach).
- When calling on the PATCH https://api-worldcheck.refinitiv.com/v2/cases/{caseSystemId} endpoint, a full screening is executed.
- There is no additional cost for the full/delta screening. If you would like to perform delta screening, you simply have to follow the steps and suggestions per the documentation:
Please let me know if you have any further questions and I am happy to help.
Blessings,
Judith
1
Answers
-
Hello @tonatiuh.flores - thank you for reaching out to us. I will be looking into your query and have answers to your questions by Monday. Thank you for your patience!
Blessings,
Judith
0 -
Thanks @judith.pillado.lseg
0 -
Hi @judith.pillado.lseg thanks for you response,. I would like to know if there is any news about this topic?
0 -
Thanks for your response @judith.pillado.lseg. Last questions, is there a difference between the patch endpoint and request full or delta screening endpoint? Besides obviously being able to update, is there a difference in re-screening?
0 -
Hello @tonatiuh.flores - thank you for your question. There isn't a difference between both endpoints rescreening-wise, but I will investigate further and if I find any differences, I will post them on this thread. Thanks,
Judith
0 -
Hi @judith.pillado.lseg, what happens if a Request full or delta screening of a case was deleted? What will be the answer? generates an error?
0 -
Hello @tonatiuh.flores - thank you for your question. When a case has been deleted, then you would get a 404 (if you are inputting an appropriate request body). Below is an example of a case I archived and then deleted:
Unfortunately, when you delete a case, there is no error cause as seen above. However, when you archive a case, it does give you the specific error (400 HTTP):
I would encourage you to download and test the several endpoints we offer here, and if you have any further questions, please let me know.
Blessings,
Judith
1 -
We are going to consider the information you gave to me. Thanks @judith.pillado.lseg for your answer. I would like to ask another question but it is about signing text signature I'm not getting correctly. I understand this could be another topic, so I'm going to ask it into another thread. Thanks again!
0 -
@tonatiuh.flores - You are most welcome. Thanks!
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 中文论坛