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

# Results

> The recommendation, the result for each area and the summary.

```json theme={null}
{
  "id": "scr_7c9e6679742540de944be07fc1f77c3a",
  "object": "screening",
  "livemode": true,
  "status": "completed",
  "request_key": "acct-0061x00000AbCdE-1",
  "reference": "0061x00000AbCdE",
  "policy": "basic-onboarding",
  "recommendation": "review",
  "categories": [
    {"category": "restrictions", "result": "clear", "reasons": []},
    {"category": "organization", "result": "note", "reasons": [
      {"code": "affiliation_not_confirmed", "message": "Could not confirm the individual's link to the organization."}
    ]},
    {"category": "scientist", "result": "clear", "reasons": []}
  ],
  "summary": "Recommendation: Review\nRestrictions: Clear. No sanctions, export-control or watchlist match was found.\nOrganization: Note. Could not confirm the individual's link to the organization.\nScientist: Clear. ...",
  "created_at": "2026-11-03T14:02:11Z",
  "completed_at": "2026-11-03T14:03:09Z",
  "decision": null
}
```

| Field | Meaning |
| - | - |
| `id` | An opaque string of up to 255 characters. Do not parse it. |
| `livemode` | `false` for a screening created with a test key. |
| `status` | `pending`, `completed` or `failed`. Only a completed screening has a recommendation. |
| `recommendation` | `approve`, `review` or `deny`. Store it in a field you can filter. |
| `categories` | One entry for each area your policy checks, in a fixed order. |
| `categories[].result` | `clear`, `note`, `flag` or `not_checked`. |
| `categories[].reasons` | Why a result is not `clear`, as `{code, message}` pairs. |
| `summary` | Plain text of at most 1,000 characters for a reviewer or a customer-management field. The first line gives the recommendation; each later line gives one area and its result. Links are full URLs. |
| `decision` | The latest decision you recorded, or `null`. |
| `error` | Present only when `status` is `failed`. |

## Areas and results

The areas are `restrictions`, `organization`, `scientist` and `address`. A
policy checks only some of them; the address area appears only when your policy
checks addresses. `organization` covers both whether the organization is real
and whether the customer works there; its reason codes say which part needs
attention.

* `clear`: the policy's criteria were met.
* `note`: something needs a person's attention, such as evidence that could not
  be found or a check that could not finish.
* `flag`: a check found evidence of a concern. A flag does not by itself show
  malicious intent.
* `not_checked`: the request did not include the information this area needs.

There is no numeric score.

## Reason codes

Reason codes are stable, so your code can branch on them. Messages may change.
The API reference tab lists the current codes.

## Unknown values

New areas, results, reason codes and fields may appear without notice. Treat an
unknown `recommendation` as `review` and an unknown category `result` as
`note`, and ignore fields you do not recognize.

## Record a decision

`POST /v1/screenings/{id}/decision` keeps your decision with the screening:

```json theme={null}
{
  "action": "approved",
  "reason": "Affiliation confirmed by email with the lab head.",
  "decided_by": "compliance@example.com"
}
```

`action` is `approved`, `refused`, `more_information_requested` or `reported`.
Each call adds a decision to the screening's audit record; the screening shows
the latest. Keeping screening records remains your responsibility.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.