Skip to main content
Vector stores are reusable retrieval resources. This guide covers their lifecycle and direct search; pass retrieved context into a Response when building an answer grounded in your files. First upload your files. Keep their file IDs for the examples below.

Create a vector store

Create a vector store and attach one or more uploaded file IDs.
This response returns a vector store ID such as vs_abc123.

Add more files later

You can add more files to an existing vector store without recreating it.
The vector store file can return status: "in_progress" while indexing runs. A file is not searchable until its status reaches "completed" — searching before then succeeds but omits the file, so poll for "completed" rather than assuming a fixed wait. Indexing usually finishes in seconds, but latency varies with file size and load. Check the Files and Vector Stores endpoints in the API Reference for the polling endpoint (for example, GET /vector_stores/{vector_store_id}/files/{file_id}).

Search the vector store

Use semantic search to retrieve the most relevant chunks for a user question.
The response returns ranked matches with file_id, filename, score data, chunk content, and the file’s current attributes.

Filter search by file attributes

Attributes are file-level key-value metadata — string, number, or boolean values — set when you attach a file (see Add more files later). You can change them after ingest with the update-file endpoint (POST /vector_stores/{vector_store_id}/files/{file_id}); search always evaluates the current values. Pass filters in the search request to restrict results to files whose attributes match. A filter is either a comparison — eq, ne, gt, gte, lt, lte, in, nin — or an and/or compound of nested filters.
Filter evaluation follows these rules:
  • A file that does not have the filter’s key never matches — including for ne and nin. A filter only opts a file in on evidence, never by absence.
  • eq and ne are strict equality with no type coercion: the string "2" does not equal the number 2.
  • gt, gte, lt, and lte compare numbers only; a non-numeric attribute or filter value fails the comparison.
  • in and nin take an array value and test whether the file’s attribute is (or is not) one of its elements.
  • and and or compounds nest to any depth.
  • On graph stores, filtering is applied after retrieval, so a filtered search can return fewer than max_num_results matches.

Typical workflow

Use this sequence for most retrieval setups:
  1. Upload the source file.
  2. Create a vector store with file_ids, or attach the file later.
  3. Wait for file processing to complete (for example, file status: "processed", and vector-store file indexing status: "completed").
  4. Search the vector store when you need relevant context.
You can then feed the returned text into your own application logic or a Responses request. For graph-aware search, see Graph retrieval.