Assessment API reference

The production web API is https://pentriarch.com/api. User-facing routes require a valid Supabase user session through a supported cookie or bearer token. Never expose service-role credentials or executor secrets in a client integration.

Examples use placeholders and require your authorised target. Account and deployment gates apply. Agree API support and stability before building a production dependency.

Lists the signed-in user’s targets. limit defaults to 100 and is capped at 250. The response contains a targets array, which may be empty. Cursor pagination is not documented for this route.

Plans and starts an assessment. prompt is required and limited to 500 characters by the planner. Reference an onboarded target using targetId and its target value. depth and focus influence planning.

The response combines planning output with run information. Use the returned planId or scanId appropriately; check the actual status and task coverage separately.

When enabled, this performs hosted inspection over http or sse. targetId is required; an optional url must remain on the owned target’s host. transport defaults to http. Static inspection is the default.

The response includes scanId, traceId, server, fingerprint, surface, attestation, certification, activeProbes, summary and findings. An active request has separate gates and may report activeProbes.status as blocked. Static success is not active-test success.

POST /api/assessment-pack returns the plan and the prospective deliverable pack for a target before a run. GET /api/scans/{scanId}/pack returns the issued pack for a scan you own, including its source (frozen or log copy) and recomputed integrity. Add ?document=<kind> to download one document as Markdown; a document that fails integrity returns 409.

POST /api/assessment-pack/verify is public and rate limited. It returns validity flags only and never stored content.

Replays the stored proof of each finding against the scan’s own host and re-runs the same validator. Send an optional findingIds array to retest selected findings. Up to 50 findings are replayed per request, and the route is rate limited.

Each result carries the stable finding identifier and one of: still_open, verified_fixed, regressed, inconclusive or not_retested. The issued report is never modified; the retest is recorded separately.

401: missing authentication. 400: rejected input. 403: permission or policy restriction. 404: missing target or disabled feature. 429: rate or account limit. Investigate 5xx responses with a redacted error and traceId.

Respect returned rate-limit headers. After a scan-start timeout, check whether a run exists before retrying; a blind retry can duplicate work. Route-specific and account-specific limits vary.