AccessPreflightAPI documentation
Open console
Ship with confidence

Track regressions without erasing debt

Baselines answer “what changed?” Suppressions answer “which known finding is intentionally excluded from current release evaluation?” Neither changes the original evidence.

Compatible baseline comparison

Create a scan with options.compare_to_baseline, or request a diff after completion:

curl --fail-with-body \
  --url "https://api.accesspreflight.com/v1/scans/${SCAN_ID}/diff?baseline=${BASELINE_SCAN_ID}" \
  --header "Authorization: Bearer ${ACCESSPREFLIGHT_API_KEY}"

The response groups fingerprints into:

  • new: present in the current scan only;
  • recurring: present in both scans;
  • resolved: present in the baseline only.

Comparison requires compatible asset type, concrete profile set, and fingerprint algorithm version. A conflict is safer than a misleading diff.

Select a baseline intentionally

A useful baseline is a reviewed release, not merely the newest scan. Record the release, source revision, profile versions, and manual-review state associated with it.

Do not silently replace a baseline after a failed build; that converts regressions into accepted debt.

Suppress narrowly

Create a suppression in the console only after a person has reviewed the finding. Project API keys with rule-packs:read can list suppressions for reconciliation, but cannot create or revoke them. Include:

  • project and finding/fingerprint scope;
  • a concrete reason;
  • the approving actor;
  • an expiry when the exception is temporary.

Suppressions retain the finding and appear in reports. Expired suppressions stop affecting release evaluation.

Good and bad exception reasons

Good: “Third-party payment widget; vendor ticket PAY-1842; compensating keyboard path reviewed; expires before contract renewal.”

Bad: “False positive” with no owner, analysis, or expiry.

Regression workflow

  1. Block or triage new blocker/critical/major fingerprints.
  2. Keep recurring debt visible in the workbook.
  3. Review resolved findings to confirm the fix did not come from missing content or reduced coverage.
  4. Revisit active and soon-expiring suppressions.
  5. Complete manual checks for the current release even when the automated diff is empty.

Search documentation