Skip to main content
This documentation is being written. Self-hosting, Developers and Reference are current and describe the platform as it stands. The user guide is not written yet — it covers the admin screens and the flow canvas, and describing an interface from the outside is how documentation drifts from the product. It follows once each screen can be walked through.
FaPost Core is an Apache-2.0 framework for conversational assistants, for developers in the Laravel ecosystem. Build your own product on top of it, keep your code closed, ship it to your clients and charge for it. The licence covers Core and both extension packages; the only thing it holds back is the name. An assistant connects to messaging channels such as Telegram and WhatsApp, holds conversations with contacts, and runs them through flows designed on a visual canvas — with contacts, segments, broadcasts, and conversation history around it. This repository is Core: the platform itself, without vertical product packages.

Why FaPost, and not another open constructor

Open flow constructors exist and have communities of their own. Three things here are different. The licence lets you build a business on top. Apache 2.0 applies to Core and to fapost/foundation and fapost/support, the packages an extension actually depends on. A Solution you write stays yours, under whatever licence you choose, and can be sold. There is no copyleft obligation to negotiate away. Only the FaPost name is reserved, by the Trademark Policy. Conversation is the unit of work, not a workflow run. A session belongs to one contact, waits for a reply for as long as the reply takes, keeps what it has collected, and resumes exactly where it stopped. Contacts, segments, conversation history and broadcasts are part of the platform rather than storage you wire up yourself — a general-purpose automation tool models an execution, not a person mid-conversation. You extend it in Laravel, not in a plugin language. A node type is a PHP class registered by a service provider; the admin panel is Filament, the builder is Inertia and Vue, the queues are Horizon. An extension is a Composer package that depends on fapost/foundation and never on App\…. There is no bespoke runtime, DSL or plugin SDK between you and the code — see the extension model for what that looks like.
A flow is a directed graph, stored as JSON, that describes a conversation. Each node does one thing — send a message, wait for a reply, branch on a condition, call an HTTP endpoint, query a knowledge base — and edges connect a node’s outcomes to whatever comes next.At runtime an engine walks that graph for one contact, resolving each node’s handler by the pair (type, version) and keeping the conversation’s state between steps. A node handler never decides which node runs next: it reports which outcome occurred, and the graph decides where that leads.That separation is what makes a flow editable by someone who does not write code, and a node reusable in flows its author never saw.

What you can build

Most installations start as a bot that answers questions on one channel. The platform is not limited to that: an assistant can qualify leads, run a multi-step intake form, notify a team, look up records in another system through an HTTP call, or broadcast to a segment of contacts on a schedule. Tenancy is not a layer bolted on top — it is a coordinate of the runtime. One installation serves many independent organisations, each with its own assistants, contacts, channels, and data, isolated in its own schema.

Where to go

User guide

Build an assistant, design flows, manage contacts and broadcasts. For the people who run it day to day.

Self-hosting

Install, run, and upgrade FaPost on your own infrastructure. For whoever keeps the servers.

Developers

Build a Solution or Plugin, or work on Core itself — including the local development environment and what the platform is made of.

Reference

Contracts, schemas, queues, commands.

What happens when someone writes

A contact sends a message. The assistant looks up which flow should handle it and starts a session — one contact moving through one flow. The session runs from node to node until the flow ends or reaches a node that waits for a reply. While it waits, the session stays open. When the contact answers, it picks up exactly where it stopped, with everything collected so far still in place. Two consequences are worth knowing before you build anything: A published flow is a snapshot. A session holds the version of the flow it started with. Publishing a change affects the next conversation, not the ones already in progress — so nobody finds the questions changing underneath them mid-conversation. A broadcast never delays a reply. Large sends are paced separately from conversation traffic, so a mailout to fifty thousand contacts does not put the person who just asked a question behind a queue.

Status

The platform is pre-1.0 and in active development. Where a feature is not finished, these pages say so rather than describing an intention as a fact — and the user guide names the screens it has not been written for yet.