Trigger a Lighthouse scan for a playlist
Queues a fresh Lighthouse scan for the playlist. Returns immediately with
202 Accepted; the new result lands at GET :id/lighthouse once the job
completes. Manual triggers are rarely needed — every company create and
update auto-queues a scan — but are useful when an out-of-band change
(DNS, CDN, theme deploy) should be re-scored without a resource write.
Authorizations
Bearer token authentication. Accepts company-admin tokens with
storefront.view for read operations and storefront.update
for writes and scan triggers (legacy per-resource grants like
categories.update / products.view / etc. are still accepted
during the migration), required on every company operation.
Storefront public operations under /api/v202604/{resource} and
/api/v202604/{resource}/{slug} are unauthenticated
(security: []).
Path Parameters
The unique identifier of the playlist.
Response
Scan accepted and queued.
Response from POST :id/lighthouse and POST :id/compliance — the
scan was accepted and queued, and the body carries the meta
envelope. The new result lands at the corresponding GET endpoint
when the job completes.
"Lighthouse scan queued"
Progress of an async lighthouse / compliance scan. Only status
is guaranteed (requested_at is present in practice once a scan
is requested); nil timestamps are omitted, so the present keys
vary by phase — a failed scan carries failed_at + error, a
completed one carries started_at + completed_at.
PascalCase type name of the scanned resource.
Category, Collection, Product, Library, Medium, Post, EnrollmentPack, Page "Category"
4821
Response metadata included on every successful response body.
request_id and timestamp are always present; list endpoints
also add pagination.