List and search assets
Paginated list of the caller's assets, newest-created first. Every filter is optional and they compose: ?tag=cat&mime=image/jpeg&minWidth=2000.
Each row is an AssetSummary — what an asset is called, what it is, how it is labelled and published, and when it expires. The image facts, metadata and lineage are only on GET /api/v1/assets/{id}. To walk a whole library, follow meta.nextCursor as cursor rather than counting pages: a cursor page counts nothing. A chain job's intermediate products are left out unless includeIntermediate=true.
USE THIS WHEN:
- Listing a view (all, published) or one collection
- Filtering by tag, MIME type, pixel dimensions, capture date or source operation
- Free-text search over the name and camera make/model
DO NOT USE WHEN:
- Retrieving a single asset by ID → use GET /api/v1/assets/{id}
- Listing the collections that exist → use GET /api/v1/assets/collections
Request
- Base URL: https://api.imagestep.dev
- URL: https://api.imagestep.dev/api/v1/assets
- Auth: API key in header Authorization
Query parameters
Page number (0-indexed). Leave it out when you send cursor
Items per page (max 100; out of range is clamped)
The meta.nextCursor of the previous page: the rows after it, read without counting — the way to walk a long listing. Send it unchanged, with the same filters; it cannot be combined with page
Which slice of the library to read: ALL, or PUBLISHED for only the assets that carry a publicUrl
Collection (an opaque label you set on upload, on a job or with POST /api/v1/assets/update), matched exactly; omit for every collection
One of your tags, matched exactly (case included) against the tags you set on upload or with POST /api/v1/assets/update
Whether the asset is in a collection at all: false is everything you have not filed, which no other filter can express. Cannot be combined with collection, which already says the asset is in one
MIME type as stored (image.mimeType), matched exactly, e.g. image/jpeg
The job that produced these assets — everything one run left behind. An upload has no job and never matches
The op that produced these assets (their lineage.op), as GET /api/v1/ops names it. Recorded when the job was submitted with an op, and on each segment of a chain: an upload never matches, and neither does the output of a job submitted by type or by a one-segment preset
Where it came from: an upload, or the kind of job that made it
Pixel width lower bound (inclusive)
Pixel width upper bound (inclusive)
Pixel height lower bound (inclusive)
Pixel height upper bound (inclusive)
Capture date lower bound — the asset's takenAt, its capture time: DateTimeOriginal, else CreateDate, else GPSDateTime (UTC). Epoch millis, or an ISO-8601 date or instant read as UTC: 2026-09-14, 2026-09-14T08:30:00Z. An image that records no capture date never matches a capture bound
Capture date upper bound. Same forms as takenFrom; a bare date includes the whole of that day
Created-at lower bound — when this service made or ingested the asset, which is the axis an automation's output lies along. Epoch millis, or an ISO-8601 date or instant read as UTC: 2026-09-14, 2026-09-14T08:30:00Z
Created-at upper bound. Same forms as createdFrom; a bare date includes the whole of that day
Ingest state: PROCESSING while the worker is still reading the bytes, DONE once it can be processed or published, FAILED for an upload whose ingest never finished (a tombstone — it expires a day after it was made and does not count against your plan)
Free text: a substring of the name or of the camera make and model, case-insensitive
Include a chain job's intermediate products — the asset one segment made for the next to read (imagestep#246). They are out of the library by default: they exist for as long as the run does, and are deleted when their item settles.
Response
One page of rows; meta carries hasMore and nextCursor
Changes
No recorded changes to this operation across all 1 revision of this API.