Skip to main content
Adaptive Decision provides a tenant-specific decision for a submission (for example: APPROVED, DECLINED, MANUAL_REVIEW). The exact decision values and reasoning are configured per tenant.
This guide uses the default EU base URL (https://api.documents.resistant.ai).
If your tenant is in another cell (e.g., us-1, ca-1, ap-2, ap-3), use the corresponding base URL described in Concepts.

When to use Adaptive Decision

Use Adaptive Decision if you want:
  • a single machine-readable decision output you can route in your workflow
  • an optional human-readable reason label to support review and audit trails
  • a stable interface even if underlying fraud indicators evolve
If you need the detailed evidence (indicators, metadata), fetch /fraud directly and store the full payload alongside the decision.

Prerequisites

Adaptive Decision is available only if:
  • the submission is created with enable_decision: true, and
  • Adaptive Decision is configured for your tenant.
If you did not enable it at submission creation, the decision endpoint will return a client error.

Enable Adaptive Decision

Enable it when creating the submission:
{
  "pipeline_configuration": "FRAUD_ONLY",
  "enable_decision": true
}
See: Core Integration Mechanics → Create a submission.

Fetch the decision

Endpoint

GET https://api.documents.resistant.ai/v2/submission/{submission_id}/decision
Authorization: Bearer <access_token>

Query parameter: embed (optional)

Use embed to include full embedded data for selected decision_inputs.
ParameterTypeExampleDescription
embedstringfraudComma-separated list of decision input keys to embed in full (example: ?embed=fraud).
Example:
GET https://api.documents.resistant.ai/v2/submission/{submission_id}/decision?embed=fraud
Authorization: Bearer <access_token>
If you need the full fraud payload including indicator metadata (e.g., bounding boxes), fetch /fraud directly (and use with_metadata=true when needed).

Responses (per OpenAPI)

200 OK — decision available

{
  "status": "SUCCESS",
  "decision": "APPROVED",
  "decision_inputs": {
    "fraud": {
      "url": "/v2/submission/submission123/fraud",
      "data": {
        "status": "SUCCESS",
        "score": "NORMAL"
      }
    }
  },
  "adaptive_decision_version": "string",
  "reason": {
    "sub_reason": {
      "value": "string",
      "label": "string"
    }
  }
}
Key fields
  • decision: your tenant-specific decision output
  • adaptive_decision_version: version of the tenant configuration used to decide
  • decision_inputs: links to the underlying inputs (and optionally embedded data if requested)
  • reason: optional explanation object (tenant-dependent)

400 Bad Request — decision not enabled

If the submission was not created with enable_decision: true, the API returns 400.

404 Not Found — decision not ready or submission not found

If the decision is not ready yet (or the submission does not exist), the API may return 404.
If 404 persists, verify the submission_id and confirm you’re calling the correct stage/cell base URL (the same one where the submission was created).

Non-success decision status

The API may return a non-success decision payload with status in:
  • FAILED
  • INVALID_INPUT
  • INVALID_PIPELINE_CONFIG
  • SKIPPED
Example shape:
{
  "status": "FAILED",
  "message": "string",
  "adaptive_decision_version": "string"
}

  • Store the decision response together with the underlying fraud result for auditability.
  • Treat SUCCESS as “decision available”; handle other statuses according to your workflow (e.g., route to manual review on failures).
  • If you rely on reason.label, treat it as tenant-configured text (do not hardcode business logic on it).

Common issues

Confirm the submission was created with enable_decision: true.
Confirm the submission exists and you are using the correct base URL for the same stage/cell where the submission was created.
Fetch /frauddirectly and store that payload alongside the decision. Use with_metadata=truewhen you need indicator metadata for visualization.

Next steps