MySQL data in Dixa

Show MySQL customer data inside Dixa conversations, queried live whenever an agent opens a conversation. No ETL, no sync lag, no code.

MySQL is the most widely deployed relational database, and for many teams it's where customer-critical data lives: accounts, orders, subscriptions, usage, permissions. Dixa doesn't know about any of that by default, so agents end up tab-switching to an internal admin or database client, searching by email or ID, and pasting the answer back into the conversation. A minute here, two minutes there. On a busy shift that adds up to hours.

FactBranch fixes that by running a live MySQL query every time a Dixa conversation is opened, and rendering the result as a Custom Card alongside the conversation. The agent sees the data they need without leaving Dixa.

How it works

FactBranch is a visual pipeline builder, not an ETL tool. There's no data warehouse in the middle, no sync schedule to tune, no copies of customer records sitting in a third-party database. Dixa passes the conversation context (requester email, conversation ID, and anything else you want) to FactBranch via a Custom Card webhook. FactBranch runs your SQL query against your own MySQL database, using the conversation context as parameters. The results are rendered into an HTML Card you design.

Each step is a node in the visual editor. You write one SQL query and one HTML template. Everything else — the Dixa integration, the parameter passing, the connection pool, the rendering — FactBranch handles.

Connecting to MySQL

You add your MySQL connection once: hostname, database, credentials. FactBranch recommends a dedicated read-only user for this — a MySQL user with SELECT on only the tables you want to expose. If your database is behind a firewall, FactBranch can route requests through a static IP so you can safely allowlist us.

Writing the query

You write the query directly against your own MySQL database. Conversation context is available as variables you can reference inline: email address, conversation ID, anything else Dixa sends through. Run the query against your live database from the editor to see results before you hook it up to the Custom Card.

What you show is up to you. A typical SaaS support team might surface the customer's current plan, MRR, and trial state; their most recent invoice and payment status; open tickets or incidents linked to their account. E-commerce teams show recent orders, fulfilment status, and lifetime value. Internal-tool teams show permissions and recent activity. If you can write it as a SQL query, you can put it in the Dixa Custom Card.

Designing the Custom Card

Once your query returns results, FactBranch pipes them into a display node where you design the Dixa Card. There's a "Generate a UI" button that produces a working HTML template from the shape of your query results — a sensible starting point you can then edit. You can tweak the template directly, add conditionals for empty or edge-case data, and style it with CSS. The templating language is Jinja2-compatible.

Keeping it safe

Your MySQL database stays where it is. FactBranch connects out to it with a dedicated read-only user — we recommend creating a MySQL user for FactBranch with the minimum privileges it needs, usually SELECT on the specific tables you want to expose. If your database is behind a firewall, FactBranch can route requests through a static IP so you can safely allowlist us. For extra isolation, run queries against a read replica instead of your primary — the integration works the same way.

Credentials are stored encrypted. We don't cache query results by default, so every conversation gets a fresh read; there's no stale data to worry about, and no long-lived copies of your data in our systems.

Setup

Most teams are live in about 15 minutes. Create a free FactBranch account, add a MySQL connection with read-only credentials, write the SQL query you want the Card to run, and design the Card layout in the display node. The final step is adding the FactBranch Custom Card URL in your Dixa settings — agents see the Card on the next conversation they open.

See the full walkthrough in our Dixa Custom Card documentation or watch a support agent use the sidebar in practice.