Start the Sonela Gateway
One small service, on one server, next to the data it reads. It dials out to us over port 443 and asks whether there is work — you open no inbound ports.
Paste one script tag into your ERP, CRM or internal tool and your staff can just ask it questions. Answers come strictly from your own material. It won't invent a number or hand you half of one: when the data can't answer, it says so.
This is the whole change to your app
Your widget key replaces the placeholder.
14 days, 200 answered questions, no card. It won't guess on your data. No AI key to supply — trials run on Sonela's key.
| Customer | Late | Avg days |
|---|---|---|
| Northwind Foods | 4 | 1.8 |
| Adriatic Retail | 3 | 2.3 |
| Vilna Grocers | 2 | 1.5 |
Your database sits inside your private network, and it stays there. Of the three steps below, only the last one touches your application.
One small service, on one server, next to the data it reads. It dials out to us over port 443 and asks whether there is work — you open no inbound ports.
The gateway reads your schema from inside your network and drafts a manifest. You hide what shouldn't be visible, confirm the tenant column, and approve.
Drop the snippet in and the assistant appears. Nothing secret reaches the page: the widget key is public by design, and who the user is stays a server-side decision.
<script src="https://api.sonela.ai/ data-key="pk_live_…" defer></script>sonela.js"
Built for the software you already run — line-of-business apps, CRMs, ERPs and internal tools, where the answers are sitting in a database nobody has time to query.
Answers come from your own material — a query against your live operational data, or the procedures you gave the workspace. When neither can answer, Sonela says so instead of inventing a number.
Model-written SQL passes an allowlist grammar before it runs, and each table reference is rewritten into a tenant-filtered subquery. Anything unexpected is rejected, not executed. And a table is never offered to the model at all if one of its columns is named like a secret — api_key, password, token: the whole table stays out of the schema it can read.
PostgreSQL is supported today. SQL Server and MySQL are next — each ships only with its full safety-test suite, because the SQL layer is the security boundary.
Bring your own — Gemini, OpenAI, Azure OpenAI or any OpenAI-compatible endpoint — and your rows reach only that provider, under your agreement. Or run on Sonela's key: they reach the provider we run, under ours.
Colours, name and greeting are set from your dashboard and apply live — no redeploy to restyle the assistant.
Your admins see questions, answer rates, latency and token spend per customer and per model — counts and costs only, never the text of anyone's question.
If the AI service times out, is rate-limited or blocks a response, that comes back as a failure — never as a blank answer or an invented one — and a passing hiccup is retried before anyone sees it.
The named reason comes back on the authenticated endpoint; the widget in your app says only that the assistant is unavailable, because naming your provider's fault to an end user describes your setup to a stranger. And when a result is too large to read in full, the assistant is told what it did not see, so it cannot imply it saw everything.
The same five stops, in the same order, every time — whether the question is about last month's shipments or the returns policy you wrote yourself.
In the app they already have open, in the words they would use with a colleague. Nothing to learn, no report to request, nobody to queue behind.
Your data in the shape you approved, the procedures and policies you uploaded, the context you wrote for your workspace — that is the material it thinks with, and the vocabulary it answers in. It is not guessing at your industry from the outside.
Right then, from your live records — not a copy, not last night's export. It can only reach the tables you approved, so a question about anything else has nowhere to go, however well it is put. It sees one customer's rows — the ones the embed is for — and it can only read them.
The real numbers where there are numbers, and a short table when a list is the honest way to show one — never a chart to go and read for yourself. When your data cannot support an answer, that is the answer: the preview at the top of this page closes on exactly that exchange, and it is the product working rather than failing.
The conversation lives in the browser tab and goes when the tab does. What your rows said passes through us and one AI provider to compose this one answer, and is written down nowhere — not in a transcript, not in a cache another question could reach.
Letting an AI read your operational data is a trust decision. Here is exactly what happens to it — including the parts most vendors leave out.
An allowlist validator refuses anything that isn't a single SELECT. What survives runs inside a READ ONLY transaction, under a three-second statement timeout and a cap of 500 rows, which the database engine itself will not let write. And that transaction is rolled back rather than committed, whatever it did.
Every table reference is rewritten into a tenant-filtered subquery before execution. The tenant identity is bound server-side from a verified token — the browser can't assert it, and the model never sees it.
Answers grounded in your data are structurally uncacheable. Chat transcripts stay in the visitor's browser. Our metering stores counts, latency and token totals — never a question, an answer, or a line of SQL.
Whatever the gateway needs to reach your data is configured inside your network and stays there: run that way there is nothing for us to store, the field on your workspace holds null, and what we keep is a hash of the gateway's key.
An AI key you bring is encrypted with AES-256-GCM, bound to its own row, and no API we expose reads it back.
The rules reach the model before any of your content does, and everything the workspace supplies — the question someone typed, the procedures you uploaded, the context you set — is handed over under an explicit instruction to treat it as data with no authority to change them.
And it does not have to hold: the read-only grammar and the tenant rewrite run after the model has spoken, so content that talked it into something still cannot write, and still cannot reach another tenant.
| Data | What actually happens |
|---|---|
| The question someone types | Reaches Sonela and one AI provider — the one you chose if you brought a key, the one we run if you did not. It is not stored afterwards. |
| Rows returned by a query | Pass through Sonela's memory to compose the answer, and reach that same provider. Never written to our disks. |
| How your data is reached | By the gateway you run, from inside your network. What it needs to do that is configured there and stays there. |
| Your AI provider key | If you bring one: encrypted at rest, never returned by any API. On Sonela's key: there is none of yours to hold. |
| Written material you upload | Procedures, notes and policies you give the assistant are kept in your workspace — that is what they are for — and go to the same AI provider with the question. Only your workspace can read them; deleting them, or the workspace, removes them. |
| Chat transcripts | Held in the visitor's browser for the conversation. We keep none. |
| Question or answer text in our metering | Never collected — counts, latency and tokens only. |
| Write access to your data | None, by design. There is no code path that writes. |
Sonela is a data processor: your questions and the rows that answer them transit our service and one AI provider — yours or ours, depending on the plan you pick.
Three plans, and one choice inside each: bring your own AI key, or run on ours. Either way what you pay us is flat and does not move when your usage does. Prices in USD, excluding VAT.
Your own key: you pay that provider directly, under your own
agreement with them — included balances are higher because the model cost is not
ours.
Sonela's key: nothing to set up. Your rows reach the provider we
run, under our agreement, on a model we pick for cost — that cost is ours, which is
why those prices are higher and the included balances lower.
Always on Sonela's AI key
14 days, no card. After 14 days or 200 answered questions the workspace pauses — everything you configured (schema, context, settings) survives and resumes the moment you choose a plan.
Regular price
For a live assistant inside one product or workspace.
Regular price
For vendors embedding the assistant across a customer base.
Need more, or something on-premise? Tell us what you need.
An email address. No card, and no AI key — a trial runs on Sonela's key, on a model we pick, under our agreement with the provider. It lasts 14 days or 200 answered questions, whichever comes first.
You do not need your data connected on day one. Start by giving the assistant your own written material — procedures, product notes, policies — and it answers from that, and says plainly that it cannot see live records yet. Bring your operational data in through the gateway when you are ready: it is the same workspace, and everything you set up stays set up.
No. Three independent layers stop it: the validator only permits a single read query, that query runs inside a READ ONLY transaction the engine will not let write, and the transaction is rolled back rather than committed. Even a compromised model can't write.
Nothing. The gateway sits inside your network and dials out to us over port 443, so there is no inbound port to open and nothing of yours exposed to the internet. Whatever it needs to reach your data is configured on your side and stays there; what we hold of it is a hash of the gateway's key, plus the schema manifest you approved.
Yes — that is exactly what the Sonela Gateway is for. It is one small service you run on one server inside your own network, next to the data it reads. It reaches out to us and asks whether there is work; we do not dial into it.
Everything that matters happens on your side of the firewall: the gateway checks the query, applies your tenant filter, runs it read-only and sends back the rows. Nothing lands on anyone's desk, and there is nothing for your team to install on staff machines.
Yours or ours — it is a choice on each paid plan, and it moves both the price and the included balance of answered questions. Bring your own key and your rows reach only the provider you chose, under the agreement you already hold with them. Run on Sonela's key and they reach the provider we run, under our agreement, on a model we pick for cost. Trials always run on our key, so there is nothing to configure to start one.
PostgreSQL today; SQL Server and MySQL are next, and each ships only once its full safety-test suite passes. For AI: Gemini, OpenAI, Azure OpenAI, or any OpenAI-compatible endpoint if you bring your own key — or Sonela's key, where we run the provider and choose the model.
Every query is rewritten so each table reference is filtered by tenant before it runs. The tenant identity comes from a token your server signs, never from the browser — so a user editing JavaScript in the page can't reach another tenant's rows.
No. We train nothing, and we don't use your data to improve the service for anyone else. Your rows go to one AI provider and no further: the one you chose under your own terms if you brought a key, or the one we run under ours if you did not.
It says so. Sonela answers from your own material — a query against your live operational data, or the procedures you gave the workspace — so when neither can support an answer it reports that instead of guessing: a wrong number delivered confidently is worse than no number at all.
It fails out loud. A passing glitch — a rate limit, a bad minute at the provider — is retried first; what survives that is reported as a failure, never as a blank answer and never as a guess. The specific reason — timed out, rate-limited, safety-blocked — comes back on the authenticated endpoint; the widget your staff use says only that the assistant is unavailable, because naming your provider's fault to whoever is on the page would describe your setup to a stranger.
Open a workspace yourself and be asking it questions in minutes — or write to us first and we will walk you through it.
14 days, 200 answered questions, no card. It won't guess on your data. No AI key to supply — trials run on Sonela's key.