Bind a list that stays in sync

The feed keeps a file current; a list bound to that file becomes the searchable, always-fresh mirror of your system. The interesting part is what happens when your data changes.

Create a list and bind it

Create a list — catalog — and, if you want search by meaning (your manifest marked description as vectorised), attach an embedding model. Then bind it to the feed's file with keep in sync on and create fields on, so the roles your manifest declared are set up for you.

POST https://api.searchstack.dev/list
X-API-Key: {your key}
Content-Type: application/json

{ "account_name": "Demo", "list_name": "catalog", "subscription_name": "Basic", "model_name": "google-gemini-embedding-2" }

POST https://api.searchstack.dev/search-result/Demo/catalog/import-from-media
X-API-Key: {your key}
Content-Type: application/json

{ "store_name": "default", "file_path": "feeds/catalog-api.ndjson", "keep_in_sync": true, "create_fields": true }

Deletes propagate too

This is where the snapshot: true line earns its place. Most sync only ever adds and updates — delete a row in your system and the stale copy lingers in search. Because your endpoint declares itself a complete snapshot, Search Stack does a set difference on each sync: any record that's in the list but no longer in your feed is deactivated. Sell out a product, retire a page, close a record — it leaves search on the next sync, with nothing for you to do.

So the full lifecycle is covered from the one endpoint: a new row appears as a new record, an edited row updates in place (matched by its id), and a removed row drops out. That's what "stays in sync" actually means — not just fresher, but faithful.

Checkpoint. Your catalog list mirrors your system and keeps mirroring it — inserts, edits and deletes — with no export and no upload. From here it's an ordinary searchable list. Next: use it in your app.

Go deeper: Binding a list, keep-in-sync, and snapshot deletion in the reference.