Hi everyone,
We're building an integration with the World-Check One API and implementing Ongoing Screening (OGS) with push notifications. We have a few questions we couldn't confirm from the docs — sharing full technical details below so you can help us spot any issues.
Issue 1 — No OGS_UPDATE notification after editing a case on the WC1 platform
Our setup:
We create cases via POST /v2/cases/screeningRequest with ONGOING state already set:
{
"caseId": "ENTITY001_CompanyName",
"groupId": "<your-group-id>",
"nameTransposition": false,
"providerTypes": ["WATCHLIST"],
"caseScreeningState": {
"WATCHLIST": "ONGOING"
},
"entityType": "INDIVIDUAL",
"name": "Test Entity",
"secondaryFields": [
{ "typeId": "SFCT_193", "value": "BR-CPF" },
{ "typeId": "SFCT_191", "value": "12345678900" },
{ "typeId": "SFCT_3", "value": "BRA" }
]
}
For cases already created in INITIAL state, we switch to ONGOING via PATCH /v2/cases/{caseSystemId}:
{
"caseScreeningState": {
"watchlist": "ONGOING",
"mediaCheck": "ONGOING"
}
}
Response: HTTP 200 OK — the case transitions to ONGOING successfully.
The test:
We created a case directly on the WC1 platform UI (not via API) and set it to ONGOING. We then edited the case's date of birth through the platform and waited for an OGS_UPDATE notification on our webhook (event type: OGS_UPDATES).
No notification was received.
Question: Does editing case data on the WC1 platform UI while in ONGOING state automatically trigger a re-screening and OGS_UPDATE notification? Or does re-screening need to be explicitly triggered via API even after a platform-side edit (e.g., PATCH
/cases/{id}?screen=DELTA_SYNC)?
Issue 2 — Media Check OGS: expected notification payload structure
We plan to enable mediaCheck: "ONGOING" alongside watchlist: "ONGOING". When we receive an OGS_UPDATE for a Watchlist event, the payload looks like this:
{
"eventType": "OGS_UPDATE",
"eventObjectId": "<caseSystemId>",
"eventPayload": {
"groupId": "<your-group-id>",
"watchlist": {
"numberOfNewResults": 2,
"numberOfUpdatedResults": 0
}
}
}
Questions:
- When the OGS update is Media Check-related, does eventPayload contain a mediaCheck object alongside (or instead of) watchlist? Something like:
{
"eventPayload": {
"groupId": "<your-group-id>",
"mediaCheck": {
"numberOfNewResults": 1,
"numberOfUpdatedResults": 0
}
}
}
- Can both watchlist and mediaCheck appear in the same eventPayload if both have updates?
- Is there a cadence/frequency for Media Check re-evaluation, or does it fire whenever new articles are indexed?
We want to make sure we're parsing the webhook payload correctly and not missing Media Check updates.
Issue 3 — Client Watchlist PUT returns 404 on v3
We're attempting to register entities in a Client Watchlist to programmatically trigger OGS updates. Our call:
PUT https://api.risk.lseg.com/screening/v3/references/providers/client-watchlist/{identifier}
Authorization: Signature keyId="...",algorithm="hmac-sha256",...
Content-Type: application/json
{
"type": {
"identifier": "CLIENT_WATCHLIST",
"name": "Client Watchlist"
},
"entities": [
{
"name": "Test Entity",
"entityType": "INDIVIDUAL"
}
]
}
Response: HTTP 404 with body [] (empty array, no error message).
We're using the v3 base URL and HMAC credentials from the same account that owns the subscription. Is Client Watchlist a separate entitlement that needs to be enabled on the account? If so, what is the process to request it?
Environment:
- Auth: HMAC-SHA256
- Case API: https://api-worldcheck.refinitiv.com/v2/
- Subscription/v3 API: https://api.risk.lseg.com/screening/v3/
- Subscription event type: OGS_UPDATES
- Environment: Homologation
Any help from those who've implemented OGS end-to-end is much appreciated. Thanks!
