List the org's stored files
const url = 'https://api.adversarial.com/api/v1/files?page=1&page_size=25';const options = {method: 'GET'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url 'https://api.adversarial.com/api/v1/files?page=1&page_size=25'Parameters
Section titled “Parameters”Query Parameters
Section titled “Query Parameters”Kinds to include, repeatable (?kind=report&kind=compliance_document).
Empty means “every kind I am allowed to see” — see the handler for why an
explicit ask and an absent one are gated differently.
Lifecycle statuses to include, repeatable
(?status=pending&status=ready). Empty defaults to ready alone, so a
plain catalogue does not advertise rows whose bytes do not exist yet;
ask for pending/failed explicitly to follow a report being generated.
1-indexed page number. Defaults to 1; zero is rejected.
Rows per page. Defaults to 25, max 100; zero is rejected.
Responses
Section titled “Responses”Paginated list of stored files
Paginated list envelope: { "results": [...], "pagination": {...} }.
object
Pagination metadata describing the slice.
object
1-indexed page number of this result slice.
Number of items requested per page.
Total number of matching items across all pages.
Total number of pages at this page size.
The items on this page.
One row of the stored-file listing (GET /v1/files).
This is the shape a catalogue needs — what it is, when it appeared, who asked for it, and where to get it.
object_key, org_key_id, enc_nonce_prefix and params are deliberately
absent. The first three are storage/crypto internals, and params carries
the full report descriptor — exposing it would leak the shape of every
report request an org has ever made.
object
Plaintext byte size; None until the file completes.
MIME content type.
Who requested it, as a display name. None for system-generated files or
when the requesting user has since been removed.
When the row was created.
Where to fetch the bytes. None unless status is ready — a client
cannot construct a working link for a row that has no bytes yet, and
omitting it keeps that unrepresentable rather than merely discouraged.
Why the file failed, when status is failed. Always a message written by
the server for display — producers sanitize before persisting it, so the
underlying storage/builder error is never echoed here.
The stored file’s id.
The file’s kind, which is also what gates its download.
Display name (for a report, its generated filename).
Lifecycle status (pending / ready / failed).
Example
{ "results": [ { "status": "pending" } ]}Missing the permission a requested kind requires