connectconceptbeta

your product

run ixi processes from your own app, and use ixi tables as a headless CMS.

You build a process in ixi, then run it from your own product: your server starts runs, and your app shows the conversation, so your users never need an ixi account. Separately, any ixi table can serve as a database for your site or app.

your server starts the run; your app hosts the conversation.

embed a process

A process is a canvas with declared inputs and a pixie that works it. The Pixie Run API lets your server:

  1. start a run of that process with input values, using an org API key
  2. hand a short-lived ticket to the browser
  3. let the browser host the run's conversation with the pixie-agent package: the user watches the pixie work, answers its questions and gets the results

The key stays on your server. The ticket covers one run for about 15 minutes. Runs spend your org's credits and count against 200 spawns per key per day.

Make a key under Organization settings → API keys; see secrets and API keys. Endpoints, the SDK and examples are in the Pixie Run API reference.

tables as a headless CMS

A Table node is a real table. With the same org key your server can query, search and edit its rows, and changes appear on the open canvas within seconds. Use it for a product catalogue, a content calendar, or a list your pixies keep filled. Reference: Table API.

how it fits

  • Processes are what you embed. Tables are what you serve.
  • MCP is for a person's AI assistant. The APIs here are for software.
  • The org key is the same one for both APIs.

things people trip over

  • A key must never go in a browser or app bundle.
  • Revoking a key kills its outstanding tickets at once.
  • Writes through the Table API are capped per key per day.
  • An embedded run is a normal run: it can pause to ask the user a question.

where next

checked against the product · 2026-10-23