# Failures and Reconfirms

Source: https://docs.pitchpointsolutions.com/developer_guides/sessions_and_workflows/failures_and_reconfirms/

**Beta**

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.

```bash
curl -X GET "https://api.pointservices.com/riskinsight-services-ws/resources/v1/workflows/wfpop_0000000000002080001" \
  -H "Authorization: Bearer your_access_token_here"
```

```json
{
  "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.

> **API Reference:** [Read a Workflow](https://docs.pitchpointsolutions.com/api/workflow/get_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.

```bash
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.

> **Warning:** 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.

> **API Reference:** [Reconfirm a Workflow](https://docs.pitchpointsolutions.com/api/workflow/reconfirm_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.

```bash
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](https://docs.pitchpointsolutions.com/developer_guides/sessions_and_workflows/retrying_safely/). This works only if you sent a distinctive `correlationId`, so always send one when you start a workflow.

> **API Reference:** [Find Workflows](https://docs.pitchpointsolutions.com/api/workflow/list_workflows/) covers which `correlationId` is searched, which are not, and the result limits.