Your orchestrator keeps the workflow. Pulse takes the part orchestrators are bad at: high-frequency, stateful, real-time stream processing. The integration surface is identical everywhere — only the client node changes:
| Surface | What it does |
|---|
POST /api/pulse/x/<app>/in | send an event into your deployed app |
GET /api/pulse/events/<topic> | read a stage's output topic |
GET /api/pulse/events/stream | SSE — push instead of poll |
pulse-py client.duplex() | correlated WebSocket — one round-trip for synchronous decisions |
So the pattern is always the same three steps: pulse deploy . the streaming step → add an HTTP call to your workflow → read the result topic. There is a guide for all 14 orchestrators, each grounded in a validated example shipped in the repo (examples/*-pulse-bridge/).
Status legend — ✅ ran E2E in repo: the example installed the real orchestrator and ran the flow end-to-end against live Pulse · 🧪 validated live: the whole definition runs validated against live Pulse via a local runner, but the host is a managed cloud service (or a server the CI sandbox can't download) — same integration, only the boot differs.
Low-code / visual
| Guide | Pulse plugs in as | Status |
|---|
| n8n | HTTP Request node ×2 | ✅ ran E2E in repo |
| Node-RED | http request node ×2 | ✅ ran E2E in repo |
Code orchestrators (Python)
| Guide | Pulse plugs in as | Status |
|---|
| LangGraph | graph node | ✅ ran E2E in repo |
| Prefect | @task | ✅ ran E2E in repo |
| Dagster | @op | ✅ ran E2E in repo |
| Airflow | TaskFlow @task | ✅ ran E2E in repo |
| Temporal | Activity | 🧪 activity validated live |
Code orchestrators (JVM)
Declarative / cloud
Because the surface is generic HTTP, this list is illustrative, not exhaustive — adding the next orchestrator is one client node. All-in-one stack: the repo's examples/orchestrators-compose/ (docker compose up: Pulse + n8n + Temporal, --profile kestra|airflow|worker for the rest); full matrix in docs/PULSE-ORCHESTRATOR-INTEGRATIONS.md.