Skip to content
steelabs

Example

Audit API collection and recurring comparison kit

A Postman collection and opt-in weekly CI example for creating audits, respecting polling limits and comparing like-for-like results without extending report retention.

Download editable MarkdownDownload API and comparison kit v1.0.0 (ZIP)

How to use this

Useful for: Website owners who want repeatable audit observations and an explicit baseline comparison.

  1. Use the kit only for a public website you own or are authorised to audit. Start with manual execution before enabling its optional weekly schedule.

  2. Keep the audit settings identical between baseline and follow-up. A different device, crawl depth, rule version or accessibility setting makes a score change unsuitable as a direct improvement claim.

  3. Treat an edit token as a secret. The example stores it only in the execution environment and avoids publishing it in a collection, browser link, report or log.

  4. Choose artifact retention and workflow notifications before enabling recurrence. The example stores comparison evidence in your own repository artifacts; live service records continue to expire after 30 days.

Scope and limitations: Scheduling runs in the owner’s CI environment after explicit enablement. The website does not silently subscribe visitors, retain audit histories indefinitely or send a new notification stream.

Document preview

# Audit API and comparison kit — version 1.0.0

## One-off run
Import the included Postman collection. Configure the public service origin and the target URL in a private environment. Create an audit, retain its edit token privately and poll the returned identifier until it is done or failed. Use the API documentation for current limits and error responses.

The collection contains request templates for creation, reading, rerunning and deletion. Ownership-changing actions require the edit token. Reading a report or attachment by identifier does not; possession of that link is sufficient. Avoid confidential notes and attachments.

## Polling
Use a bounded deadline, wait between requests and respect Retry-After when present. Stop on a final failed status rather than retrying forever. The example runner performs a new scoped audit and reports a queue or provider failure clearly.

## Comparable evidence
Match target, requested device, maximum pages, accessibility setting and rule version. Align results by page path and check identifier. Distinguish a newly failed check from a missing page or a changed observation on an already failed check. The comparison interface can inspect two existing reports without saving another server-side history.

## Optional recurrence
The example workflow is manually triggered by default. Its README shows how to enable a weekly schedule. A repository owner chooses the target, settings, retention period and whether a regression should fail the job. Workflow notifications follow that repository's settings; no mail address is collected by this site.

## Retention boundaries
Temporary audit records, attachments and PDFs retain the service's 30-day expiry. A saved comparison artifact is a separate copy under the repository owner's control. Set a short artifact retention period and delete local copies when no longer needed. Never include the edit token in that artifact.

## Interpretation
An automated comparison describes selected response rules at two times. It does not test authenticated workflows, prove accessibility conformance or certify security. Repeat important user journeys independently and assign owners to the changes that warrant investigation.

Read alongside this worksheet

Get help applying itAll resources