SDK Architecture

Ironflow provides three SDKs that communicate with the server through different protocols. The browser SDK connects inward via WebSocket or ConnectRPC for real-time subscriptions. In push mode, the server connects outward to user endpoints via HTTP POST. In pull mode, workers connect inward and poll the server over HTTP for jobs (an opt-in ConnectRPC streaming worker is also available). The @ironflow/core package provides shared types, schemas, and error classes used by both browser and node packages. A fourth SDK, sdk/python, is Tier 1 like the Go and Node SDKs — it ships a polling worker (ironflow.worker) and a push ASGI handler (ironflow.serve) — and is named on the diagram’s card rather than drawn. @ironflow/langgraph is also outside the diagram: it is an integration package, not an SDK layer — a LangGraph checkpoint saver backed by entity streams. @ironflow/agent is outside it too: it is the Ironflow agent for ACP editors, a tool you run, not a client library.