Ask your app a question in plain words.

Fidara is a chat layer for your application's data. It answers each user inside their own role's scope, on your own infrastructure.

You expose three HTTP webhooks and add an <iframe>. The model pipeline, query validation, SQL generation, conversation storage and the chat screen come with Fidara.

What Fidara is

Fidara is one service: a backend, its own PostgreSQL database and a pre-built chat screen. It adds a natural-language layer to any application that is backed by a database, such as an ERP, a CRM, an internal tool or a customer portal. The app developer writes no model code and no query logic.

It does not replace your screens. A question that a list view already answers is a slower trip to the same screen. Fidara is for the questions that need more than one screen: totals by group, rankings, comparisons between periods, and spreadsheets of your own that you want checked against the app's data.

Two rules shape everything else. The model never writes SQL: it produces a structured query that Fidara checks and turns into SQL with code. And authentication stays with your app: Fidara hands your app a token and gets back a user.

What an app developer does

  1. Expose three webhooks

    verify turns a token into a user. catalogue lists the tables, columns and row scope that user may use. query runs a parameterized query on your own database connection and returns rows.

    A fourth webhook, write, is optional.

  2. Set environment variables

    Point Fidara at your app and at a model: FIDARA_APP_BASE_URL, FIDARA_WEBHOOK_SECRET, FIDARA_DATABASE_URL, FIDARA_LLM_API_KEY and FIDARA_LLM_MODEL. Any OpenAI-compatible endpoint works, chosen by FIDARA_LLM_BASE_URL.

  3. Add an iframe

    Embed the chat on a page and pass the signed-in user's session token.

    <iframe src="https://fidara.example.com/?token={{ user.session_token }}"></iframe>

The contract in detail is on Integrate your app.

What Fidara does after that

  • On each request it asks your app who the user is, and which tables, columns and rows that user may read.
  • A model plans the question as a structured query in JSON. Fidara validates it and builds parameterized SQL from it with code. The user's row scope is added by code, never by the model.
  • Your app runs the SQL on its own database connection and returns the rows. Fidara never receives your database credentials.
  • Fidara shows the result as a table, a chart or a card, and keeps the conversation in its own PostgreSQL.

The same question can have a different correct answer for each person, because each person has a different scope. The demo shows this on three ERPs.

What it can do

How you run it

  • One process serves one app. It holds no call-home code.
  • The model is any OpenAI-protocol endpoint: for example DeepSeek, OpenAI, vLLM, llama.cpp or Ollama.
  • Conversations live in your own PostgreSQL. docker compose and a Dockerfile are in the repository.
  • Reference adapters exist for Dolibarr, ERPNext and Odoo, plus a plain-database sandbox. See the adapters.
LimitsFidara trusts the catalogue and the scope your adapter returns for each user. It never widens them, and it cannot tell whether an adapter returned too much. Guide needs a web page. The language model can make mistakes, so check a figure that matters in the app itself.