Skip to main content
PUT
Set a project's pull-request controls

Authorizations

Authorization
string
header
required

An Earnie API key, sent as Authorization: Bearer sk_earnie_.... Create one under Settings > API keys. The key's scopes decide which operations it may call.

Path Parameters

projectId
string<uuid>
required

Body

application/json

Per-project pull-request controls. Presentation controls govern how much Earnie says about a pull request it scanned; noise controls govern which pull requests are worth scanning at all. Neither governs what a scan concludes: no control here reaches policy evaluation, the gate, a finding state or a verdict, so no setting on this object can turn a block into a pass.

summary_comment
enum<string>
required

always posts the summary on every terminal verdict, success included — the default, and what a project with no stored setting reads. on_failure_only refreshes an existing summary comment but never creates one on a passing gate: a pull request that has never failed gets no comment, while one that did stops showing a stale red verdict.

Available options:
always,
on_failure_only
inline_severity_floor
enum<string>
required

Lowest finding severity eligible for an inline review comment. Defaults to medium; lower-severity findings remain visible in Earnie and in the pull-request summary.

Available options:
critical,
high,
medium,
low,
info
inline_comment_cap
integer
required

Maximum inline comments in one COMMENT review. Defaults to 10; overflow remains in the pull-request summary. Zero disables inline placement without changing policy evaluation or the check.

Required range: 0 <= x <= 10
draft_pull_requests
enum<string>
required

What to do with a draft pull request. scan — the default, and what Earnie did before this control existed — scans it like any other. skip leaves it unscanned until it is marked ready for review, at which point the provider's ready_for_review event scans it.

Available options:
scan,
skip
bot_authors
enum<string>
required

What to do with a pull request opened by a provider bot account — a dependency updater, release automation, a code generator. scan is the default. skip leaves them unscanned, which on repositories where bots open most pull requests is the largest single source of check noise.

Available options:
scan,
skip
base_branch_filter
string[]
required

Allow-list of base-branch patterns. A pull request targeting a branch none of them matches is not scanned. EMPTY MEANS EVERY BASE BRANCH, not none. Patterns support exact names, *, ?, [], and prefix/** for a whole namespace.

Maximum array length: 50
path_filters
string[]
required

Allow-list of changed-file patterns. A pull request is scanned only when it touches at least one matching file. EMPTY MEANS EVERY PATH. Earnie scans when it cannot be sure the filter excludes the change: if the provider will not say which files changed, or answers a truncated list with no match, the pull request is scanned anyway — a filter may only suppress a scan on evidence.

Maximum array length: 50

Response

The updated pull-request feedback setting.

Per-project pull-request controls. Presentation controls govern how much Earnie says about a pull request it scanned; noise controls govern which pull requests are worth scanning at all. Neither governs what a scan concludes: no control here reaches policy evaluation, the gate, a finding state or a verdict, so no setting on this object can turn a block into a pass.

summary_comment
enum<string>
required

always posts the summary on every terminal verdict, success included — the default, and what a project with no stored setting reads. on_failure_only refreshes an existing summary comment but never creates one on a passing gate: a pull request that has never failed gets no comment, while one that did stops showing a stale red verdict.

Available options:
always,
on_failure_only
inline_severity_floor
enum<string>
required

Lowest finding severity eligible for an inline review comment. Defaults to medium; lower-severity findings remain visible in Earnie and in the pull-request summary.

Available options:
critical,
high,
medium,
low,
info
inline_comment_cap
integer
required

Maximum inline comments in one COMMENT review. Defaults to 10; overflow remains in the pull-request summary. Zero disables inline placement without changing policy evaluation or the check.

Required range: 0 <= x <= 10
draft_pull_requests
enum<string>
required

What to do with a draft pull request. scan — the default, and what Earnie did before this control existed — scans it like any other. skip leaves it unscanned until it is marked ready for review, at which point the provider's ready_for_review event scans it.

Available options:
scan,
skip
bot_authors
enum<string>
required

What to do with a pull request opened by a provider bot account — a dependency updater, release automation, a code generator. scan is the default. skip leaves them unscanned, which on repositories where bots open most pull requests is the largest single source of check noise.

Available options:
scan,
skip
base_branch_filter
string[]
required

Allow-list of base-branch patterns. A pull request targeting a branch none of them matches is not scanned. EMPTY MEANS EVERY BASE BRANCH, not none. Patterns support exact names, *, ?, [], and prefix/** for a whole namespace.

Maximum array length: 50
path_filters
string[]
required

Allow-list of changed-file patterns. A pull request is scanned only when it touches at least one matching file. EMPTY MEANS EVERY PATH. Earnie scans when it cannot be sure the filter excludes the change: if the provider will not say which files changed, or answers a truncated list with no match, the pull request is scanned anyway — a filter may only suppress a scan on evidence.

Maximum array length: 50
locked
boolean
read-only

Whether these values come from an organization lock rather than from the project. When true, PUT on this resource is refused with 409 settings_locked and the values are changed at /v1/organization/pr-feedback. Ignored in a request body.

source
enum<string>
read-only

Where the effective answer came from: organization for a locked organization layer, project for the project's own stored settings, default when neither exists. Ignored in a request body.

Available options:
default,
project,
organization