Integrations

Extend the capabilities of your workflows by connecting to external services. Integrations are the bridges between Fluxify and the rest of your technical ecosystem.

Adapter Pattern

Fluxify uses the Adapter Pattern to handle integrations.

Interface: We define a standard interface (e.g., IDbAdapter).
Implementation: Concrete classes (like PostgresAdapter) implement this interface.

This means the core system doesn't care if you are using PostgreSQL, MySQL, or MongoDB. It just talks to the generic "Database Adapter."

Benefits

Switching Providers: You can switch underlying technologies (e.g., moving from PostgreSQL to MySQL) with minimal changes to your routes.
Unified config: All credentials and settings are managed in one central place.

Production and development values

Every integration holds a production config and a development config under one name. Blocks and triggers refer to the integration, so the same route works in both environments: the production worker uses the production config and the development worker uses the development one.

Setting	What the development worker uses
Its own config (default)	The development config. With none set, a run that uses the integration fails and says `integration <name> has no development value`. It never falls back to production.
Same as production	The production config.

cfg: references in each config are read from the same environment's App Config.

Use separate development instances

Point the development config at its own database, queue or topic, and key-value store, as you would when coding a backend by hand. Triggers use the same consumer group names in both environments, so a development config that points at a production queue takes production's messages.

Same as production means development uses production

Development runs, development triggers and the AI agent read and write your production service. Turn it on only when that is safe.

Testing a connection

Action	Credentials it uses
Test connection (portal, API, MCP)	Development. For an integration set to Same as production, that is the production config.
Browsing a database's tables and columns	Development, the same way.
Test production credentials	Production. Only a signed-in person using the portal can run it. API tokens, MCP and the AI agent cannot.

If development has no config and Same as production is off, testing says so and asks you to set one.

In the portal

In the portal's integration form (both create and edit):

Same as production: A checkbox toggle. When enabled, the development form is hidden and replaced by a warning: Dev runs, dev triggers and AI agents will read and write production — same database, same queues, same consumer groups. Use separate dev instances instead.
Missing development value hint: When "Same as production" is unchecked and development credentials are blank, an inline hint indicates: Dev workers will fail until you set a development value or turn on Same as production.
Test connection: Available on both the integrations list and details page to test the development credentials. A test that is taking too long (a host that does not answer) shows a Cancel button next to it. Cancel stops the test right away and puts the page back to normal, and no result is shown.
Test production credentials: Displayed to project creators and admins alongside the dev test button.

Integrations from plugins

A plugin can add a variant of any category above, or a category of its own. Those connections appear in the same list, with a Plugin badge, and are created the same way. Integrations from plugins covers where they appear, what a disabled plugin means, and why a plugin cannot be removed while its integrations exist.

Integrations ​

Adapter Pattern ​

Benefits ​

Production and development values ​

Testing a connection ​

In the portal ​

Categories ​

Integrations from plugins ​