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!
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
0
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
0 -
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
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 688 Datastream
- 1.4K DSS
- 620 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 254 ETA
- 557 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 276 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 663 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 229 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛