Skip to main content

API Access

Document stores can be maintained from code as well as from the interface. This is how you keep a store in step with a source that changes — a product catalogue, a help centre, a nightly export.

Managing a store programmatically​

The API's most useful operation is upsert: send a file to an existing store and it's loaded, split, embedded, and indexed in one call, reusing the configuration already set up in the interface.

That's the important detail. You configure the loader, splitter, embedding model, and vector store once by hand, then the API repeats that exact setup for every file you send. Your script doesn't need to know or restate any of it.

Available operations​

OperationWhat it does
UpsertAdd or replace a document in a store, using the store's existing configuration
RefreshRe-run every loader in a store and re-index the result

These two are the whole API. Searching a store is not available to an API key — the playground requires a signed-in session, and an API-key call to it returns 401. To search a store programmatically, call a flow that contains a Retriever node through the Prediction API.

Refresh is the one to reach for when the sources changed but the configuration didn't: it re-fetches every loader, so a store built from a website or an S3 bucket can be brought up to date in a single call.

Authentication​

Requests authenticate with a workspace API key in the Authorization header:

Authorization: Bearer <your_api_key_here>

The key determines the workspace, and therefore which stores you can reach.

Open a loader row's Options → View API and Flowera shows the ready-made request for that specific store, with its ID filled in and Python, JavaScript, and cURL versions.

Example request​

Adding a file to an existing store:

curl -X POST https://<your-flowera-domain>/api/v1/document-store/upsert/<storeId> \
  -H "Authorization: Bearer <your_api_key_here>" \
  -F "files=@./handbook-2026.pdf" \
  -F "docId=<loaderId>" \
  -F "replaceExisting=true"
FieldWhat it does
filesThe file to load
docIdThe existing loader whose configuration to reuse
replaceExistingtrue replaces that loader's chunks; false adds alongside them
loaderNameOptional label for the loader
splitter, embedding, vectorStore, recordManagerOptional overrides — omit them to keep the store's settings

replaceExisting=true is what you want for a document that gets a new version. Leave it false and every sync adds another copy of the same content, which quietly degrades retrieval as duplicates crowd out other results.

Keeping a store in sync​

A nightly job that re-uploads changed documents is usually all you need:

  1. Build the store by hand once — loader, splitter, embeddings, vector store.
  2. Note the store ID and loader ID from the Upsert API dialog.
  3. Have your job POST each changed file with replaceExisting=true.
  4. Add a Record Manager to the store first (see Vector store) so repeated upserts update rather than duplicate.

Remember every upsert re-embeds what it sends, which costs a little. Sync what changed, not everything.