Handle Results
After you create a Hosted Flow evaluation, RiskOS™ returns an initial response that starts the hosted session. This response is used to launch the Hosted Flow and track the evaluation, but it does not represent the final onboarding outcome.
Important:
The initial response is not the final decision. Always use the
evaluation_completedwebhook for the final result.
Initial response
What happens next
For Hosted Flow, the initial response typically includes:
decision: "REVIEW"status: "ON_HOLD"eval_status: "evaluation_paused"redirect_uri
This indicates that:
- The hosted session was created successfully
- The evaluation is paused
- User interaction is required to continue
What to do
When your application receives the response:
- Persist the
eval_idfor tracking and correlation - Extract the
redirect_uri - Redirect the user to the hosted experience
- Wait for the webhook to deliver the final decision
Example response
{
"eval_id": "296652a5-0a17-4e9f-8f2c-534076fefcd7",
"decision": "REVIEW",
"status": "ON_HOLD",
"eval_status": "evaluation_paused",
"redirect_uri": "https://riskos.sandbox.socure.com/hosted/xyz"
}Key fields
| Field | Description |
|---|---|
eval_id | Unique identifier for the evaluation (persist this). |
decision | Initial state (REVIEW is expected). |
status | ON_HOLD means waiting for user interaction. |
eval_status | evaluation_paused means the flow is in progress. |
redirect_uri | URL to launch the Hosted Flow. |
Redirect the user
Immediately redirect the user to the redirect_uri.
During the hosted session, RiskOS™ handles:
- Identity data collection
- Fraud checks
- Watchlist screening
- Optional One-Time Passcode and Document Verification (DocV)
Your application does not collect PII during this step.
Web integration
If integrating in a web application, redirect the user to the hosted redirect_uri. You may open it in the same tab or a new tab.
window.location.href = hostedRedirectUriiOS integration
Launch the RiskOS™ Hosted Flow using an in-app browser such as SFSafariViewController.
import SafariServices
let safariVC = SFSafariViewController(url: URL(string: hostedRedirectUri)!)
present(safariVC, animated: true)Android
Launch the RiskOS™ Hosted Flow using Chrome Custom Tabs for a secure in-app browser experience.
val customTabsIntent = CustomTabsIntent.Builder().build()
customTabsIntent.launchUrl(this, Uri.parse(hostedRedirectUri))Returning to your
redirect_urimeans the user experience is complete — not that the evaluation is finalized.
Receive the final decision
After the Hosted Flow completes, RiskOS™ sends an evaluation_completed webhook. For the full webhook payload schema and all available response fields, see the Evaluation API Reference.
The final outcome is in:
data.decision
Example webhook
{
"event_type": "evaluation_completed",
"data": {
"eval_id": "11111111-2222-3333-4444-555555555555",
"decision": "ACCEPT",
"status": "CLOSED",
"eval_status": "evaluation_completed"
}
}Handle the final decision
Because the evaluation completes asynchronously, your frontend should wait for your backend to persist the final decision, then route the user accordingly.
RiskOS™ responses include additional fields for enrichment results, workflow context, and observability.
For a complete breakdown, see the Evaluation API Reference.
Routing logic
Your backend should expose the persisted decision to the frontend (for example, via a status endpoint).
ACCEPT→ Continue onboardingREJECT→ Route to fallback or denial flowREVIEW→ Route to manual review (if applicable)
One common approach is polling your backend until the stored decision is available.
if (data.decision === "ACCEPT") {
router.push("/success");
}
if (data.decision === "REJECT") {
router.push("/review");
}Do not use status or eval_status for business decisions.
Error handling
If the API returns an HTTP error (4xx or 5xx), your application should handle it before processing any evaluation logic.
| Status code | Meaning | What to do |
|---|---|---|
400 | Bad request — missing or invalid fields | Check request body against required fields. |
401 | Unauthorized — invalid or missing API key | Verify your Authorization header. |
404 | Not found — invalid eval_id or endpoint | Confirm the eval_id and endpoint URL. |
429 | Rate limited | Back off and retry after the Retry-After header value. |
500 | Internal server error | Retry with exponential backoff (max three attempts). |
For the full error schema and all error codes, see the Errors Reference.
Data handling
What to persist
Store these fields for tracking:
ideval_iddecisionstatuseval_statusworkflow(optional)
Implementation flow
- Start an evaluation.
- Store the
eval_id. - Redirect user to the Hosted Flow.
- Wait for webhook.
- Persist final
decision. - Route user based on outcome.
Summary
- The API response starts the session.
- The user completes verification in the Hosted Flow.
- The webhook delivers the final decision.
- Your application should act only on the webhook result.
Updated 1 day ago
