AccessPreflightAPI documentation
Open console
Understand results

Pin profiles and understand their limits

A profile is an immutable versioned selection of technical rules, requirement mappings, manual checks, and scope metadata. Profiles make scans reproducible; they do not turn preflight into legal certification.

Technical profiles target standards-oriented checks such as WCAG, EN 301 549, or PDF/UA machine rules. Legal-context profiles help frame evidence for a jurisdiction or service context.

Legal-context profiles do not decide whether a law applies to your organization or service. They can require customer-supplied declarations and leave operator, exemption, enforcement, whole-service, or counsel decisions manual or unsupported.

Discover instead of hard-coding

Use GET /v1/profiles and filter by:

  • status and default_enabled;
  • compatible asset_types;
  • profile_kind and jurisdiction;
  • required declarations;
  • engine requirements;
  • mapping and specialist-review status.

The profile object links to its machine-readable mapping and standalone XLSX mapping export.

curl --fail-with-body \
  --url 'https://api.accesspreflight.com/v1/profiles' \
  --header "Authorization: Bearer ${ACCESSPREFLIGHT_API_KEY}"

Pin concrete versions in automation

profile-id@latest resolves to a concrete immutable version at scan creation. The resolved values are recorded on the scan. For CI and evidence workflows, prefer the concrete version so configuration review and scan behavior move together.

When adopting a successor version:

  1. Read mapping and release notes.
  2. Run the old and new versions on a representative corpus.
  3. Review coverage denominator changes.
  4. Update the quality gate intentionally.
  5. Record the change in your release policy.

Mapping approval is visible

Mappings expose requirement identifiers, applicable asset type, automation classification, implemented rule IDs, source edition, source URL, limitations, and denominator totals.

Treat pending_review, required, or “mapping not independently approved” as real product metadata. Customer approval of one scan does not approve AccessPreflight's global mapping.

Rule packs add customer policy

A rule pack can pin profiles, disable rules, override severities, define manual checks, and store a quality gate. Versions are immutable so an old scan remains explainable.

Create and version rule packs in the console. Integrations with rule-packs:read can list and resolve the immutable policy selected for automation; session-only rule-pack mutation is intentionally not part of this reference.

Avoid broad rule disabling. Prefer a documented suppression when the exception belongs to one source, locator, or known period. Use a rule-pack change when the organization has intentionally changed policy for all relevant scans.

Do not compare incompatible policy sets

Baseline comparison requires compatible asset type, concrete profile set, and fingerprint algorithm. If any of these differ, the API returns a conflict instead of inventing a misleading regression diff.

Search documentation