The whole builder is a React component

Most automation platforms treat embedding as an afterthought — an iframe, a stripped-down widget, a "talk to sales" tier. FluidGrids inverts that: the first-party app is itself built on the embeddable SDK, so embedders get the real builder, not a cut-down copy.

The FluidGrids frontend SDK exposes four integration tiers. Tier one is a single component: mount the standalone builder with a workspace id, auth token, and API endpoints, and the full canvas — palette, validation, config panels, live logs — renders inside your app. Tier two splits the data layer out into a shared provider plus a headless builder core, for hosts that want multiple SDK components sharing one client pair.

Tier three is the headline: a single root component mounts the complete routed module — workflow list, builder, runs, settings — under any route in your app, like /automations. Tier four is à-la-carte: individual pages such as the executions list, execution detail, templates gallery, and the connection components, for teams composing their own information architecture.

White-labeling is prop-driven: a view-only mode for read-only surfaces, options to hide the header, sidebar, and logs panel, and your own styling hooks. Callbacks let the host react to saves, runs, node selection, and navigation, and you can hand the builder a workflow definition directly so it renders with no fetch at all.

Auth stays where it belongs: the host mints the token, the SDK forwards it, and the the platform API enforces permissions on every operation — the embedded surface is exactly as governed as the first-party app. Your customers see your product growing an automation engine; you see one npm dependency.