Retrieve Size Analysis status check rules for a project

Retrieve the current Size Analysis status check rules configured for a project.

Use this endpoint after receiving a size_analysis.completed webhook when you want external CI to evaluate the same Size Analysis status check thresholds that Sentry uses. The endpoint returns the current project configuration, not a historical snapshot from when the webhook was emitted.

The response includes whether status check enforcement is enabled and the normalized rule list Sentry uses when evaluating Size Analysis thresholds.

This endpoint requires a bearer token with project:read access. Project distribution tokens are not supported.

Response notes:

• enabled: false means status-check enforcement is disabled for the project.
• rules: [] means there are no configured thresholds to evaluate.
• value is returned as a string. For absolute and absolute_diff measurements it is a byte value; for relative_diff it is a percentage.
• filterQuery is the original configured filter string.
• filters is the machine-readable version of filterQuery.
• filters: [] means the rule has no filters and applies to all builds.
• filters: null means the saved filter query could not be parsed; Sentry's status check trigger treats that rule as non-matching.

Rule evaluation semantics:

• Threshold comparisons are strict: a rule triggers only when the computed value is greater than the configured threshold, not greater than or equal to it.
• absolute_diff and relative_diff require a matching base metric/build.
• relative_diff does not trigger when the base size is zero.
• artifactType identifies the artifact scope the rule evaluates. main_artifact, watch_artifact, android_dynamic_feature_artifact, and app_clip_artifact target their matching artifact metric. all_artifacts evaluates all available artifact metrics.
• Rule filters support the keys app_id, git_head_ref, build_configuration_name, and platform_name.
• Filter objects are combined with AND. Multiple conditions inside one filter object are combined with OR.
• Each condition uses values; single-value operators still return a one-item array.
• Values in filters are decoded literal values for exact/simple operators, not query syntax. For example, app_id:\*com in filterQuery becomes values: ["*com"] with operator: "equals".
• The same key can appear in more than one filter object when positive and negative conditions both exist; those filter objects are still combined with AND.
• Supported filter operators are equals, notEquals, in, notIn, contains, notContains, startsWith, notStartsWith, endsWith, notEndsWith, matches, and notMatches.
• matches and notMatches values use Sentry wildcard pattern syntax, not regular expressions. * matches zero or more characters, escaped \* matches a literal asterisk, and a pattern without * is an exact match.
• in and notIn are evaluated as one condition against all values, matching Sentry's status check trigger behavior.
• A rule applies only when the build metadata matches all filters. If a referenced metadata key is missing, the filter does not match, even for negated operators.