Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.flowx.ai/llms.txt

Use this file to discover all available pages before exploring further.

This guide is for developers who want to integrate FlowX with their own application or backend — for example, embedding a FlowX-driven UI inside a React app, triggering a FlowX process from a backend job, or reacting to FlowX events in a downstream system. Pick the pattern that matches what you are trying to do. Each section links to the reference docs for setup details.
Do not poll renderer-internal runtime endpoints from your own code.Endpoints under /api/runtime/process/.../status and /api/runtime/process/.../data exist for the FlowX renderers (React / Angular / iOS / Android SDKs) to refresh their own state. They are not part of the public integration surface and their contracts can change between releases without notice. If you need process state in your own app, use one of the patterns below instead.

​
Choose your pattern

If you want to…Use this patternWhy
Show FlowX-driven screens inside your existing web or mobile appRenderer SDKHandles state, validation, UI updates for you
Start a FlowX process from your backend, a scheduled job, or another servicePublic REST APIStable, documented, public endpoints
Start a FlowX process when an external system fires an HTTP callbackIncoming WebhookNo backend code needed; FlowX exposes the URL
Start a FlowX process from an event your other services already publishKafka custom integrationFits event-driven architectures
React to FlowX activity from a downstream systemKafka events outboundDecoupled, stream-based

​
1. Embed the FlowX UI with an SDK

Use a renderer SDK to render FlowX-driven UI flows and process screens inside your app. The SDK manages session state, polling, and form lifecycle — you do not need to call runtime endpoints directly.

React Renderer

Embed FlowX flows in a React application

Angular Renderer

Embed FlowX flows in an Angular application

iOS Renderer

Embed FlowX flows in a native iOS app

Android Renderer

Embed FlowX flows in a native Android app
Use this when: the UI your end users see should be driven by FlowX (forms, screens, navigation, validation). Do not use this when: you only need a backend/server-to-server integration with no UI.

​
2. Trigger a process via REST

Start a process programmatically from any HTTP-capable code (backend service, CLI, scheduled job, partner system).
1

Get the build info

Call Get Build Info with the workspace ID and app ID to retrieve the active buildId. The active policy determines which build is currently live for the runtime.
2

Start the process

Call Start process by build id and process name with the appId, buildId, and process definition name. The response contains the new process instance UUID.For UI-action scenarios where the process should inherit a resource definition from a related instance, see Start with resource definition and inherit values.
3

Locate the IDs you need

If you do not know your workspaceId, appId, or process definition name, see the Finding Identifiers and Parameters guide.
Use this when: another service needs to kick off a FlowX process and the user-facing UI (if any) is handled separately. Do not use this when: you are tempted to keep polling the runtime to track the process — switch to Kafka events or use the SDK instead.

​
3. Trigger a process from an incoming webhook

If the external system can call an HTTP endpoint, FlowX exposes a Webhook Gateway URL per resource definition. The system POSTs to the URL, FlowX starts the process. No code on your side beyond configuring the call.

Incoming Webhooks

Configure webhook-triggered processes, secure them with API keys
Use this when: integrating with a third-party SaaS that supports outbound webhooks (Slack, GitHub, payment providers, custom apps). Do not use this when: the calling system is your own backend that already speaks Kafka — pattern 4 is more efficient.

​
4. Trigger a process from a Kafka event

Build a custom integration (Connector microservice) that publishes to a Kafka topic the FlowX engine listens on, or wire an existing event stream into the engine through a topic naming convention.

Custom integrations and Kafka topics

Custom integrations overview, topic naming, Connector quickstart
Use this when: your architecture is already event-driven and you want FlowX to react to events alongside other consumers.

​
5. React to FlowX events

Run a downstream service that consumes Kafka events emitted by the FlowX engine — for example, audit forwarding, metrics, or notifications. See the custom integrations overview for topic naming and event types. Use this when: you need to mirror or transform FlowX activity into another system without coupling it to a synchronous API call.

​
Authentication

All public REST endpoints require a Bearer token issued by the configured identity provider (Keycloak by default). See Configuring an IAM solution for setup, and the Finding Identifiers and Parameters guide for retrieving the values you need to authenticate from outside the platform.
The reference pages linked above cover the most common public endpoints (build info + process start variants). FlowX exposes additional public endpoints — for example, starting workflows, fetching task views, and retrieving public data-model paths — that are not yet documented end-to-end. If you need one of those, contact the platform team and we will add it to the reference set.

​
Frequently asked

Do not poll runtime query endpoints from your own code. The supported approaches are:
  • If you need real-time process state in a UI, use a Renderer SDK — it handles state for you.
  • If you need to react to completion in another service, consume the relevant Kafka event (see pattern 5).
  • If you need a callback to your own HTTP endpoint, model that as an explicit step in the process (a Service Task that calls your URL when the process reaches that node).
You can, but you will not get FlowX’s UI state management, validation, navigation, or form generation — those live inside the renderer. If you only need to start processes from a custom UI (not render FlowX-driven screens), pattern 2 is enough. If you need FlowX-driven screens, use the React Renderer.
See the Finding Identifiers and Parameters guide. The buildId returned from Get Build Info is the one to use when starting a process from a frontend or external app.

Public REST API reference

Endpoint specs for build info and starting processes

SDKs overview

React, Angular, iOS, Android renderer SDKs

Incoming Webhooks

Trigger processes from external HTTP callbacks

Custom integrations

Kafka-based Connectors and topic naming
Last modified on May 11, 2026