DEVELOPER GUIDE

View as Markdown

Beta

Reporting Outcomes

A product can be set up for outcome-based billing: a workflow is billed according to what became of the application it supports, rather than simply because it was started. For a mortgage application, for example, you can be billed only for loans that fund, with no charge for applications that are withdrawn, denied or closed for incompleteness. The same model applies to any application a workflow supports, such as a rental that becomes a signed lease or a candidate who is hired.

PPS doesn’t see those outcomes on its own. Your approved integration system reports each one from your system of record as it happens, and the product’s configuration, agreed with PPS, decides which outcomes are billable.

Ask your PPS account manager to set up your product to take outcome reports, and to tell you which outcomes it accepts. PPS grants the permission to report to your integration system’s credential. It is separate from the permission to start workflows, so a credential that starts workflows can’t report outcomes unless it is granted that as well.

• Report an outcome
• Choose the outcome code
• How outcomes decide billing
• When to report
• What outcomes don’t change

Report an outcome

When the application behind a workflow reaches an outcome, report it on the workflow’s workflowId:

curl -X POST "https://api.pointservices.com/riskinsight-services-ws/resources/v1/workflows/wfpop_0000000000002080001/edit" \
  -H "Authorization: Bearer your_access_token_here" \
  -H "Content-Type: application/json" \
  -d '{
    "outcome": "LOAN_FUNDED"
  }'

You report only what happened. The response is the workflow as a read returns it. workflow.outcomes lists every report with whether it counted as serviceable, and workflow.serviceable is true once any of them did.

{
  "workflow": {
    "workflowId": "wfpop_0000000000002080001",
    "status": "complete",
    "serviceable": true,
    "outcomes": [
      { "reason": "LOAN_FUNDED", "serviceable": true, "reportedAt": "2026-09-14T18:22:05Z" }
    ]
  }
}

That response is trimmed to the fields that matter here.

Send the wfpop_ workflowId. An outcome is about the whole workflow, so a wfrunpop_ runId is refused with a 400.

Choose the outcome code

The outcome codes are industry-agnostic, in four groups: application outcomes, which fit an application of any kind, and outcomes specific to mortgages, tenant screening and employment screening. Report the code that fits, from whichever group describes it. Map each status in your system of record to one code before you go live.

Your product accepts only the outcomes your PPS account manager has configured for you, to suit your business process. Any other code is refused with a 400 whose message names the outcomes the product does accept, and nothing is recorded. A workflow whose product doesn’t take outcome reports refuses every outcome the same way.

Outcome codes lists every code, its meaning and, for mortgages, its HMDA action-taken code.

How outcomes decide billing

Your PPS account manager configures your product with two lists, to suit your business process: the outcomes that count as serviceable, the result you pay for, and the outcomes that don’t. Each report is judged against those lists as they stand when you report it, and the answer is kept with the report. A later change to the lists applies from the next report on, and never changes an outcome already reported.

From the first report on, the workflow is serviceable when any reported outcome is, and not serviceable when none is. A later unserviceable report doesn’t undo an earlier serviceable one. Before the first report, workflow.serviceable reflects the workflow’s billing entries instead.

Report every workflow. While your product takes outcome reports, PPS waits for the first report on each workflow before it settles that workflow’s billable status. A workflow nobody reports on stays unsettled.

When to report

• When the outcome changes, not on every sync. Every call records a new report and a new entry in the workflow’s history, so sending the same outcome on every synchronization only adds history.
• In any order. No report replaces another, and none of them is the workflow’s current outcome, so your system can send them in whatever order it learns them.
• Again, if a call fails or times out. A repeated call records the same outcome again and changes no answer, so this call takes no Idempotency-Key; just send it again.

What outcomes don’t change

Outcomes are recorded for billing. They don’t change what the Workflow API allows: a reconfirm, and every other call, is accepted or refused exactly as it would be had no outcome been reported. reconfirmAvailable is still the only gate for a reconfirm.

Edit a Workflow has the request contract and every response.