> ## Documentation Index
> Fetch the complete documentation index at: https://developers.resistant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Adaptive Decision

> Fetch a tenant-specific decision for a submission (optional).

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.

<Note>
  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](/getting-started/concepts).
</Note>

## 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

<Tip>
  If you need the detailed evidence (indicators, metadata), fetch `/fraud` directly and store the full payload alongside the decision.
</Tip>

***

## 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:

```json theme={null}
{
  "pipeline_configuration": "FRAUD_ONLY",
  "enable_decision": true
}
```

See: [Core Integration Mechanics](/integrate/core-integration) → Create a submission.

***

## Fetch the decision

### Endpoint

```http theme={null}
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`.

| Parameter | Type   | Example | Description                                                                             |
| --------- | ------ | ------- | --------------------------------------------------------------------------------------- |
| `embed`   | string | `fraud` | Comma-separated list of decision input keys to embed in full (example: `?embed=fraud`). |

Example:

```http theme={null}
GET https://api.documents.resistant.ai/v2/submission/{submission_id}/decision?embed=fraud
Authorization: Bearer <access_token>
```

<Tip>
  If you need the full fraud payload including indicator metadata (e.g., bounding boxes), fetch `/fraud` directly (and use `with_metadata=true` when needed).
</Tip>

***

## Responses (per OpenAPI)

### 200 OK — decision available

```json theme={null}
{
  "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`.

<Tip>
  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).
</Tip>

### 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:

```json theme={null}
{
  "status": "FAILED",
  "message": "string",
  "adaptive_decision_version": "string"
}
```

***

## Recommended integration behavior

* 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

<AccordionGroup>
  <Accordion title="I get 400 Bad Request">
    Confirm the submission was created with <code>enable\_decision: true</code>

    .
  </Accordion>

  <Accordion title="I get 404 repeatedly">
    Confirm the submission exists and you are using the correct base URL for the same stage/cell where the submission was created.
  </Accordion>

  <Accordion title="I need the full evidence behind the decision">
    Fetch <code>/fraud</code>

    directly and store that payload alongside the decision. Use <code>with\_metadata=true</code>

    when you need indicator metadata for visualization.
  </Accordion>
</AccordionGroup>

***

## Next steps

* [Downloadable PDF report](/integrate/pdf-report)
* [Polling for results](/receiving-results/polling)
* [Core Integration Mechanics](/integrate/core-integration)