REST API data in Dixa

Call any REST API from Dixa conversations and show the response in a Custom Card, live on every open. No code, no glue backend, no sync.

Most customer systems of record expose a REST API: your own product, your billing provider, your shipping provider, your internal services. Dixa agents usually need data from one of those APIs to answer conversations — but making API calls from inside Dixa traditionally means building a custom integration or middleware backend. Most teams skip it and tab-switch instead, copying emails and order IDs across open tabs until they find the answer.

FactBranch is the glue that removes that cost. It calls your API live every time a Dixa conversation is opened, passes the conversation context as parameters, and renders the response as a Custom Card alongside the conversation. No code, no backend to maintain.

How it works

FactBranch is a visual pipeline builder, not an ETL tool. There's no intermediate data store, no sync schedule to tune. Dixa passes the conversation context (requester email, conversation ID, and anything else you want) to FactBranch via a Custom Card webhook. FactBranch makes an HTTP request to your API — with conversation context interpolated into the URL, headers, query parameters, or body — and renders the JSON response as an HTML Card.

Each step is a node in the visual editor. You configure one API request and one HTML template. Everything else — the Dixa integration, the authentication, the parameter passing, the JSON parsing, the rendering — FactBranch handles.

Connecting to your API

You add the connection once — base URL and authentication. FactBranch handles most patterns out of the box: API keys in headers, Bearer tokens, basic auth, and OAuth with automatic token refresh.

Configuring the request

You configure the HTTP request much like you would in a tool like Postman: method, URL, headers, query parameters, body. Conversation context is available as variables you can interpolate into any of those pieces, so you can hit /customers?email=..., /orders/{conversation_id}, or any other pattern your API supports. Run the request from the editor to see the exact JSON response before you wire it up to the Custom Card.

For APIs that return paginated results, you can loop through pages and merge the data. For APIs that need multiple calls (look up a customer, then their orders), you can chain nodes so one request's output is the next one's input.

Designing the Custom Card

Once you have the JSON response, FactBranch pipes it 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 response — a sensible starting point you can then edit. You can tweak the template directly, add conditionals for missing fields, style it with CSS, and loop over arrays. The templating language is Jinja2-compatible.

Keeping it safe

Your API stays where it is. FactBranch calls it from the server side — credentials never leave our backend, and your API surface isn't exposed to the browser. We recommend creating a dedicated API credential for FactBranch with the minimum scope it needs. If your API is behind an IP allowlist, FactBranch can route requests through a static IP so you can safely include us.

Credentials are stored encrypted. We don't cache API responses by default, so every conversation gets a fresh call; there's no stale data to worry about.

Setup

Most teams are live in about 15 minutes. Create a free FactBranch account, add a REST API connection with the right auth scheme, configure the request using conversation context variables, 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 REST API documentation or watch a support agent use the sidebar in practice.