Media Stores

A media store is where your files live: the images your results show, and the data files (JSON, NDJSON or delimited text such as CSV) you build a list from.

• Storage you control. The platform reads from it to fill in results and import records.
• Every account starts with the built-in Search Stack Storage store, and every new list uses it until you pick another.
• Connect your own cloud bucket (a top-level folder in a service like Amazon S3) to keep the files in your account.
• Each list’s store is a sortable column on Lists. Change it from that row’s … menu — Change Media Store, or Add Media Store where none is chosen — or from the list’s own Options menu.

Auto-plays · use Back / Next to step through at your own pace.

Connect a media store

1. Go to Media. The built-in Search Stack Storage store is already there.
2. Click Add Media Store and pick a provider: Azure Blob Storage, Amazon S3, Cloudflare R2 or Firebase Storage.
3. Give it a name and its connection details, then click Add. Your files stay in your account; the platform reads only what it needs.

How much the built-in store holds

• 100 MB in total across every file in the account. The Storage column on Media shows how full it is (13 MB of 100 MB), amber at three quarters and red at nine tenths. An upload that would cross the line is refused; nothing is dropped to make room.
• 10 MB for a single file uploaded through the console or the API. Larger files arrive another way — a feed saving what it fetched, or you writing into your own bucket.
• No plan raises the 100 MB; connect your own bucket instead.
• Neither limit applies to your own store: not capped, not measured, so Storage shows a dash.

Connect a Cloudflare R2 bucket

Cloudflare R2 connects like Amazon S3, except it identifies storage by Cloudflare Account ID instead of an AWS region — we reach your bucket at <account-id>.r2.cloudflarestorage.com. Pick Cloudflare R2 and fill in four things:

• Account ID — from the R2 overview page.
• Bucket — the R2 bucket holding your files.
• Access Key Id and Secret Access Key — the S3-style pair from an R2 API token.
• The token — R2 → Manage R2 API Tokens in the Cloudflare dashboard, with Object Read & Write on the bucket. Read-only suffices to display images and import files; console uploads need read and write. The key id and secret are shown once. See Cloudflare’s S3 API tokens guide.
• CORS — browser uploads need a rule allowing PUT, under Settings → CORS policy. Reading files and showing images need none.

Import records from a file

Point a list at a media store and build it from a data file there: a products.json or catalogue.csv becomes searchable records, no code required.

• Start from the file — Import into list… on the file’s own row, then pick the list (or make one). The columns are confirmed on the next screen.
• Formats — JSON, NDJSON, and delimited text (.csv, .psv, .tsv, .tab). Commas, semicolons, pipes or tabs are worked out from the file itself.
• Sync badge — each imported record remembers where it came from, so file-fed records are told apart from ones added by hand or through the API. Every list reading a file is named on its row; a file no list reads says so.
• A feed’s own file is not imported from here — open the list and choose Connect a feed.
• Convert to feed format… — rewrites a .csv, .psv, .tsv or .tab one record per line, into a new file beside it. The original is kept. Use it when a file is too big to import as it stands: the converted one imports with no size limit. Expect it to be well over twice the size, and both count against the store.
• See Imports.

Edit the file in the console, and re-import automatically

• Edit in place — any importable file (JSON, NDJSON, delimited text) up to 5 MB, including the file a feed saves for itself, so you can see what a sync fetched.
• Automatic re-import — a regular check keeps the list in step with the file. It adds and updates records; it never deletes.
• On every plan, the free one included. No idle timer, nothing to restart.
• Files you cannot edit (a picture, a PDF, an archive) are offered as a download. Images also preview, with their size in pixels; over 20 MB the preview is skipped.

Images in results

Upload a picture against a record (or store it in your bucket) and a resource field carries its URL, so results show thumbnails and posters from your own storage. For searching by an image, see Image Search.

Moving a list to a different media store

Change Media Store takes the list’s files with it. Records point at files by their path inside a store (posters/9f8a.jpg, not a full address), so files left behind would mean images that stop appearing.

• Files are copied first, and the list keeps using its current store the whole time. It reads the new store only once every file has arrived; you are told when it finishes.
• If a file cannot be copied the list stays put, still working, and you are told what failed. Re-run once fixed — files already copied are skipped.
• One move at a time. A list with no media changes store immediately.
• Moving back to the built-in store copies into its 100 MB cap, so a large list may not fit — you are told, rather than left with a broken list.

Reading a stored file back

A record names a file by path, not URL — a temporary link would expire inside your records within hours, a path never does. Turn a path back into a picture with GET /media/{account}/{list}/{path}.

• Needs search-result:read, the same permission that returned the record, so a browser-safe search key can show the image.
• Limited to one list, so it cannot browse the rest of your store.
• Small files return bytes; large ones redirect to a short-lived link from your provider, which is what makes a stored video usable in a <video> tag.

Filling your store from URLs your records already hold

Where records point at somebody else’s images, the capture gate downloads each one on the way in and rewrites the field to a path in your store.