Prodantix
At a glance
- Category
- Developer platform
- Website
- prodantix.com
- Console
- app.prodantix.com
- Documentation
- prodantix.com/en/docs/overview
- GraphQL API
- api.prodantix.com/graphql
- Event ingestion
- eu.api.prodantix.com/v1/events
- Realtime
- eu.ws.prodantix.com
- MCP surface
- eu.mcp.prodantix.com/mcp
- Session replay
- eu.replay.prodantix.com
Prodantix is made for the people who build software. Every product team keeps asking the same three questions: what are people actually doing inside our app, who should be allowed to see which parts of it, and when is the right moment to say something to them.
Most companies buy a different tool for each of those jobs, and that is where the trouble starts. Each tool keeps its own separate record of who your users are, and those records slowly drift apart. One tool thinks a customer has finished setting up her account. Another has not caught up, so it emails her instructions for a step she completed last week. Nobody spots it until she complains, or until two dashboards start showing different numbers.
How the engine is put together
Four primitives make up the engine, and everything else is built on them. They are worth taking in order, because each one feeds the next. The concepts reference covers them in full.
Event
A single thing a user did, captured as it happens: a sign-up completed, a page opened, a form abandoned halfway. Events are the raw signal, and they are the only thing entered into the system from outside. Everything else is derived from them.
User state
A live, queryable projection of everything known about a user, derived from their events and updated the moment a new one arrives. This is the source of truth that analytics, feature flags and messaging all read. It is not a nightly rollup, and it is not a copy that some job keeps in step. There is one of it.
Decision
A rule evaluated against user state: who belongs to a cohort, who gets a flag, who qualifies for a message. Because a decision reads live state at the moment it is asked, it cannot be answering from a stale picture.
Action
What the engine does when a decision fires: expose a feature, send a message, start a workflow. An action is itself recorded as an event, which is what lets the loop close: what the engine did becomes part of what it knows.
Analytics is reading the state
Analytics in Prodantix is not a separate store holding its own copy of your users. It is reading user state directly. Funnels, retention and cohorts are queries over the same live projection the rest of the engine acts on, so there is no SQL round trip to a warehouse and no waiting for a nightly rollup: the state is already shaped for the question. Cohorts here are first-class objects: named, defined by clauses, with membership kept current as people qualify and stop qualifying.
Showing different things to different people
Teams often want to release something new to a handful of users first and see how it goes before everyone gets it. Prodantix decides who sees what by evaluating conditions against user state: an attribute, an operator and a value, checked at the moment the flag is asked rather than looked up in a stored list. You can give a new feature to two percent of customers, watch how they use it, then widen it or withdraw it without waiting for another release.
Messages that arrive while they still help
A message is only worth sending while it still helps. Prodantix can send one the moment a person does something, or fails to. If a customer reaches the limit of their plan, they hear about it there and then, rather than the next morning after they have already given up and gone elsewhere.
AI orchestration, and how the loop closes
The surfaces above still leave you wiring the steps: notice something, work out who it applies to, decide what to do about it. Prodantix can run that loop itself. The engine detects the meaningful moment in live state, selects the cohort it applies to, and chooses the action. What makes this more than ordinary automation is the last part: the action is recorded as an event, so it folds back into the same user state the next decision reads. The system’s own behaviour becomes part of what it knows about that person, rather than something that happened to them off to one side.
Getting events in
Everything starts with an event sent to the ingest endpoint, which the engine folds into user state immediately. SDKs cover web, mobile and server. React is the one exception: its lifecycle needs a dedicated adapter, a provider and hook that install the client once and are StrictMode-safe. The quickstart wires it up in a few lines.
Keys and environments
Every SDK call carries a project key, which comes from the console. Creating a project produces two environments, live and test, each with its own key: build against test, ship with live. Both keys are shown exactly once, right after creation, because the server stores only a hash and no screen can reproduce them later. Rotation mints a replacement for the environment you pick, and you choose whether the old key stops working immediately or after a grace period.
Four ways to talk to it
REST spans three hosts, one for flags and messaging, one for event ingestion and one for session replay, each serving its own OpenAPI document at /openapi.json. Ingestion answers 202, which means the event was accepted for processing rather than stored: a malformed event can still be dropped further down the pipeline. GraphQL covers the full application model, including projects, flags, workflows, analytics, messaging, cohorts and billing. The realtime surface broadcasts flag changes, messages and workflow runs, and drops unauthenticated connections immediately. The MCP surface lets AI agents read and write through tool calls; it is machine to machine and refuses browser requests.
The data stays yours
You can run Prodantix on our servers or on your own, and it works the same either way. Everything you put into it, you can take out again in full, whenever you want. We do not sell your data and we do not use it to train AI models. By design Prodantix ends up holding the most complete record of your customers that you have anywhere, so that promise carries more weight here than it would elsewhere.
Who it is for
Prodantix suits teams who are running two or three separate tools for this and are tired of them disagreeing. It is most useful once you have enough customers that you can no longer keep track of what they are doing by asking around.
Visit Prodantix: prodantix.com