API REFERENCE
Beta
Mark a Finding Reviewed
Requires that at least one review note already exists on the finding — a finding cannot be resolved with no recorded explanation of why. If none exists yet, call Set a Finding’s Review Note first; calling this endpoint before a note exists returns a 400.
Requires that you currently have permission to review this finding — see Finding.editStates.resolve, which is published only once that permission is held and a note already exists, so if you see it, calling it is expected to succeed.
Sample
url="https://api.pointservices.com/riskinsight-services-ws/resources/v1/findings/workflows/wfpop_0000000000002082611/findings/fndg_0000000000006051384/resolve"
curl -X POST "${url}" \
-H "Authorization: Bearer your_access_token_here" \
-H "Content-Type: application/json"
This call takes no request body.
Header Properties
| Property | Value | Required? |
|---|---|---|
| Authorization | Bearer your token | true |
| Content-Type | application/json | true |
Path Parameters
| Property | Description | Type |
|---|---|---|
| workflowId | The opaque handle identifying the workflow. | string |
| findingId | The opaque finding identifier (fndg_…). | string |
workflowId is accepted with or without its wfpop_ prefix — a bare GUID resolves. findingId and attachmentId are not interchangeable this way: either must carry its exact prefix, or the request 404s as if that finding or attachment did not exist. There is no bare form of either that has ever been valid.
Responses
200
The finding, re-projected — byte-identical in shape to a GET of the same finding, reflecting reviewStatus now REVIEWED. See List a Workflow’s Findings for the full Finding field table.
{
"workflowId": "wfpop_0000000000002082611",
"finding": {
"findingId": "fndg_0000000000006051384",
"code": "HP.ST",
"displayName": "High-priority stated income mismatch",
"category": ["Income"],
"severity": "HIGH",
"alertState": "Cleared",
"userMessage": ["Stated income does not match the verified source document."],
"userSuggestion": ["Confirm the applicant's income against the attached document before proceeding."],
"reviewStatus": "REVIEWED",
"reviewer": "Jane Reviewer",
"reviewNote": "Confirmed with borrower via phone on 8/7; income supported by attached paystub.",
"updatedAt": "2026-08-07T15:04:09Z",
"hasAttachments": true,
"hasHistory": true,
"links": {
"self": { "href": "https://api.pointservices.com/riskinsight-services-ws/resources/v1/findings/workflows/wfpop_0000000000002082611/findings/fndg_0000000000006051384" },
"history": { "href": "https://api.pointservices.com/riskinsight-services-ws/resources/v1/findings/workflows/wfpop_0000000000002082611/findings/fndg_0000000000006051384/history" },
"attachments": { "href": "https://api.pointservices.com/riskinsight-services-ws/resources/v1/findings/workflows/wfpop_0000000000002082611/findings/fndg_0000000000006051384/attachments" }
},
"editStates": {
"reset": {
"href": "https://api.pointservices.com/riskinsight-services-ws/resources/v1/findings/workflows/wfpop_0000000000002082611/findings/fndg_0000000000006051384/reset",
"method": "POST"
}
}
}
}
alertState always reads "Cleared" on a reviewed finding, regardless of what the check itself originally reported. Resolving a finding through this endpoint is treated as authoritative over whatever the underlying check produced. Compare against the pre-resolve response above (List a Workflow’s Findings) where the same finding read "alertState": "Alert".
reviewer is a display summary only — never an internal identifier — and names whoever or whatever is recorded as having resolved the finding, including an automated process. If you need to distinguish an automated resolution from a human one, reviewer being absent is the closest available signal, but it is not a guarantee either way.
400
No review note has been recorded on this finding yet — call Set a Finding’s Review Note first.
| Property | Description | Type |
|---|---|---|
| message | A human-readable explanation of what was rejected. Not a stable code — write your handling against the status code and the operation you called, not this text. | string |
{
"message": "Finding[fndg_0000000000006051384] cannot be resolved: no review note has been recorded"
}
403
You may not read this workflow, or may read it but currently lack permission to review this finding.
Zero-length body, no Content-Type. Do not attempt to parse a body from this response — there is none. Branch on the status code alone.
This surface uses a bodyless 403 for every authorization failure, which is different from a problem+json 404 on the same operation. Do not assume every non-2xx on this API carries JSON — check the status first.
A 403 is also produced at the edge, before this service is reached, when a request value resembles SQL injection or cross-site scripting, and separately from the per-address rate limit (429). Both of those are also bodyless and carry no Content-Type.
404
Unknown workflowId or unknown findingId.
An RFC 9457 problem document, served as application/problem+json.
| Property | Description | Type |
|---|---|---|
| type | An absolute URI identifying the problem type. https://pointservices.com/problems/not-found is the only type this surface emits. This is the stable value to match on. | string |
| title | A short summary, written for a person. | string |
| status | The HTTP status code, repeated in the body. | number |
| detail | An explanation of this occurrence, written for your logs — never a stable code. | string |
| instance | A URI identifying this occurrence, written as urn:pps:request:<id>. Quote it when you raise a support ticket. | string |
{
"type": "https://pointservices.com/problems/not-found",
"title": "No such resource",
"status": 404,
"detail": "No finding fndg_0000000000006051384 is available to this request.",
"instance": "urn:pps:request:8d3a1f56-6c94-4e20-b7f8-0a5e9c2d4b73"
}
Branch on type, never on the text of detail.