> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/configuration/configuration-pull-requests.md).

# Pull Request Configuration

## Overview

The **Configure → Pull Requests** page controls how Nullify's code-review check behaves on each pull request: whether it can fail CI, what priority of finding is severe enough to fail it, and whether Nullify is allowed to submit an approving review.

These settings are tenant-wide — they apply to every connected repository — and require the **Admin** role to change. They map directly to the admin API (`PUT /admin/pr-gate-settings`), so the same behaviour can be automated.

## The Nullify check

Nullify reports a single check named **Nullify** on every pull request, covering code (SAST), dependency (SCA), and secrets analysis together. By default this check is **informational** — it reports findings but always concludes successfully, so it never blocks a merge. The settings below let you turn it into a required gate.

## Settings

### Fail CI check on findings

When **enabled**, the Nullify check reports a **failed** status when the pull request introduces at least one finding at or above the chosen [minimum priority](#minimum-priority). When **disabled** (the default), the check always passes and only surfaces findings as comments and dashboard entries.

The gate evaluates **net-new findings only** — issues this pull request introduces relative to its target branch. Pre-existing findings in the backlog never fail an unrelated pull request, so enabling the gate does not retroactively block in-flight work.

{% hint style="info" %}
Failing the check does not block the merge on its own. To turn it into a hard merge requirement, mark the **Nullify** check as required in your provider's branch-protection / merge-check rules (for example, GitHub branch protection's "Require status checks to pass").
{% endhint %}

### Minimum priority

Sets the lowest finding priority that fails the check when the gate is enabled:

* **Urgent only** — only `URGENT` findings fail the check.
* **Important and above** — both `URGENT` and `IMPORTANT` findings fail the check.

Lower-priority findings (`MEDIUM` and below) are always reported but never fail the check.

### Allow approving reviews

This setting governs only whether Nullify is allowed to **approve** a pull request. It does not change the other review verdicts.

When Nullify has a concrete security concern about code the pull request introduced or changed, it can post a review:

* **Request changes** — for critical / high-severity issues that should be fixed before merge (see **Allow request-changes reviews** below).
* **Comment** — for a security concern that should be raised but is not severe enough to block.

A pull request with no security concern receives no review comment at all; the passing **Nullify** check is the all-clear signal.

The **Allow approving reviews** toggle controls only the clean-PR case:

* **Off (default)** — Nullify never submits an approving review. A clean pull request is left without a review (the passing check is the signal).
* **On** — Nullify may submit an **approving** review on a pull request that has no blocking findings. Because a bot approval can satisfy a required-reviewer rule, this is opt-in.

{% hint style="warning" %}
Enabling approving reviews means a Nullify approval can count toward a required-reviewer rule on your branch protection. Leave this off if you want every pull request to still require a human approver.
{% endhint %}

### Allow request-changes reviews

This setting controls whether Nullify may submit a **request-changes** review when it has a blocking security concern about the pull request.

* **Off (default)** — Nullify raises blocking concerns as **comments** rather than a request-changes review.
* **On** — Nullify submits a **request-changes** review for critical / high-severity concerns. Because a request-changes review can block a merge under branch protection, this is opt-in.

This toggle is independent of the approving-reviews setting and of the CI check gate.

{% hint style="info" %}
The review verdict and the **Nullify** check are independent. The check's pass/fail comes only from the net-new finding gate ([Fail CI check on findings](#fail-ci-check-on-findings) + [Minimum priority](#minimum-priority)); a *request changes* review does not by itself fail the check, and a failing check does not depend on the review verdict.
{% endhint %}

## Equivalent API

| Setting                       | API field                       | Values                |
| ----------------------------- | ------------------------------- | --------------------- |
| Fail CI check on findings     | `enabled`                       | `true` / `false`      |
| Minimum priority              | `min_priority`                  | `URGENT`, `IMPORTANT` |
| Allow approving reviews       | `allow_approving_reviews`       | `true` / `false`      |
| Allow request-changes reviews | `allow_request_changes_reviews` | `true` / `false`      |

```http
PUT /admin/pr-gate-settings
{
  "enabled": true,
  "minPriority": "IMPORTANT",
  "allowApprovingReviews": false,
  "allowRequestChangesReviews": false
}
```

All settings default to off / `URGENT` for tenants that have never saved the page.