Beta
Failures and Reconfirms
What to do when a run fails, how to run a workflow again under the same handle, and how to find a workflow again when you have lost its handle.
When a run fails
If workflow.failed arrives instead, read the workflow to see why.
curl -X GET "https://api.pointservices.com/riskinsight-services-ws/resources/v1/workflows/wfpop_0000000000002080001" \
-H "Authorization: Bearer your_access_token_here"
{
"workflow": {
"workflowId": "wfpop_0000000000002080001",
"runId": "wfrunpop_0000000000002080001",
"sessionId": "0000000000013500001",
"correlationId": "my-workflow-0001",
"product": {
"service": "ADV",
"model": "ADV-120"
},
"status": "failed",
"serviceable": false,
"reconfirmAvailable": true
},
"messages": [
{ "code": "FAILED", "text": "/Inputs[1]/Input[1]/Loan[1]/Borrower[1]/Residence is required.", "timestamp": "2026-08-07T15:02:05Z" },
{ "code": "FAILED", "text": "/Inputs[1]/Input[1]/Loan[1]/Borrower[1]/ContactPoint is required.", "timestamp": "2026-08-07T15:02:05Z" }
]
}
status is the answer; messages is the explanation. Branch on status, never on a message code or its text.
Those paths name internal elements, not the keys you sent. Residence means the residences array on a person, and ContactPoint means contact details such as homePhone. Read them as a description of the missing fact. Fix the data, stage it again, and start another workflow.
Read a Workflow has the full status vocabulary and the message-code rules.
Trigger a reconfirm
Triggering a reconfirm runs a workflow again under the same handle: same workflowId, new runId. It is its own action, distinct from starting a workflow.
curl -X POST "https://api.pointservices.com/riskinsight-services-ws/resources/v1/workflows/wfpop_0000000000002080001" \
-H "Authorization: Bearer your_access_token_here" \
-H "Content-Type: application/json" \
-d '{
"correlationId": "my-reconfirm-0001"
}'
A reconfirm fires its own events, exactly as the first run did. The delivery carries the same workflowId and a new runId, so your handler needs no special case. A correlationId belongs to the run and is not inherited, so send a new one if you match on it.
Check reconfirmAvailable before posting. Compare it against true explicitly; it is optional on the wire, and absent means “not available”.
Send no body to re-run against the data currently staged in the workflow’s session, or terms to run against a revised set, which becomes the session’s new snapshot. Do not name a product; it is inherited.
Reconfirm a Workflow has the request contract and when reconfirmAvailable is false.
If you lose the handle
Searching by the correlationId you sent when you started the workflow finds it again.
curl -X GET "https://api.pointservices.com/riskinsight-services-ws/resources/v1/workflows?correlationId=my-workflow-0001" \
-H "Authorization: Bearer your_access_token_here"
Make your correlation ids distinctive. Matching is on the whole value, never a prefix, and there is nothing to fall back on.
This is also your recovery path after a 500 or a timeout when starting a workflow. The handle is issued before any work begins, so a workflow that started can always be found. If you sent an Idempotency-Key, retry after a timeout with the same key. Otherwise, or after a stored 500, search for the id you sent before starting another. See Retrying Safely. This works only if you sent a distinctive correlationId, so always send one when you start a workflow.
Find Workflows covers which correlationId is searched, which are not, and the result limits.