Sooket: build API middleware on a canvas - and run it inline in the request path

TL;DR — Sooket is a visual editor whose output is a live HTTP endpoint. You drag nodes, connect them, and the graph executes inside the request path — so unlike n8n/Make/Zapier (which run async, after the fact), it can actually shape the response a caller is waiting on. It's self-hosted, runs as a single Next.js process against a local SQLite file, and is source-available under FSL-1.1-MIT. Repo: github.com/danilopatrial/sooket.

The problem: every API grows a glue layer

Sooner or later, every API needs a layer of logic in front of it. Throttle abusive callers. Strip PII before it hits a third party. Cache an expensive response. Validate a token. Fan a request out to an LLM.

Today that glue is one of two things:

1. Hand-written middleware you build, test, deploy, and babysit.
2. An automation tool (n8n, Make, Zapier) — but those run asynchronously, after the fact, and can't shape the response the caller is blocking on. There's a gap between those two. Sooket is what goes in it.

What Sooket is

Sooket is a visual canvas for the logic that sits between a caller and your API. You drag nodes onto a canvas, connect them, and expose the whole pipeline as a single HTTP endpoint. Every request runs through the graph synchronously and gets a response back.

No separate service to host. No async queue. No cloud account. It runs as one Next.js process against a local SQLite file on your own machine.

The key distinction is when the logic runs relative to the request:

	Sooket	n8n / Make / Zapier
Execution model	Inline / synchronous — in the HTTP request path	Async / background, event-triggered
Shapes the caller's response?	Yes — returns the graph's output	No — fires after the fact
Primary use	API middleware (auth, rate limit, redact, cache, LLM)	Workflow automation between SaaS apps
Hosting	Self-hosted single process + SQLite	Mostly cloud / hosted runners

They solve different problems. Reach for an automation tool when you're wiring SaaS events together in the background. Reach for Sooket when something needs to happen during a request and return a response.

A concrete example: the API Guard

A fresh install ships with one workflow already on the canvas — API Guard — so there's something to open and inspect on first run:

Input -> Rate Limiter -> PII Redact -> HTTP Request -> Output

It puts rate limiting and PII redaction in front of an upstream API without touching that API's code. Callers over the limit get rejected before any work happens, PII is scrubbed before the request is forwarded, and the upstream response comes back through the same endpoint.

It ships inactive with a placeholder upstream URL. To run it for real: point the HTTP Request node at your API, toggle the workflow active, and call it with its per-workflow key:

curl -X POST http://localhost:3000/api/v1/chat \
  -H "Authorization: Bearer sk-wf-xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{"email": "[e-mail]", "note": "call me at 555-123-4567"}'

Quickstart (about 30 seconds)

Requires Node ≥ 22 (it uses the built-in node:sqlite). Check with node -v.

npx sooket          # → http://localhost:3000

Data — the SQLite database plus a generated encryption secret — lives in ~/.sooket (override with SOOKET_DATA_DIR). Or run it from source / via Docker Compose if you'd rather. Then open the canvas, build a workflow, and mint an sk-wf-* key for it from the workflow's settings.

What's actually in the box (v0.1.1)

Verified and shipping today:

• Visual canvas — a React Flow editor with auto-insert-into-edge, per-node config panels, and live sandbox testing.
• 45 nodes across AI, Request, External, Format, Logic, Transform, and Static families.
• Inline execution — POST /api/v1/chat runs the graph synchronously and returns the result.
• Webhooks — a token-gated /api/webhooks/[slug] endpoint per workflow.
• Per-workflow API keys — sk-wf-* keys with scopes, rate-limit overrides, expiry, and 30-day usage stats.
• Encrypted secrets — AES-GCM + PBKDF2 for provider keys, credentials, and variables, encrypted at rest.
• Versioning — every save snapshots nodes/edges (capped at 50); restore any previous version.
• Observability — per-request and per-node execution logs with paginated history.
• Standalone runtime — an optional execution server that shares the same SQLite file. A few of the 45 nodes worth calling out: Rate Limiter, PII Redact, Content Guardrail, Cache, Semantic Cache, Router, A/B Split, Retry, Try/Catch, Vector Upsert/Search, Sub-Workflow, and a Custom Code node for when you need an escape hatch.

How it works under the hood

A workflow is stored as nodes + edges JSON in SQLite. The request flow:

1. A caller sends POST /api/v1/chat with a Bearer sk-wf-* key.
2. Sooket resolves the key to its workflow.
3. The engine walks the node graph recursively (rate limit, redact, HTTP, LLM, …), memoising each handle so it's computed once per request.
4. The Output node's result is returned to the caller in the same response. The engine lives in lib/workflow-engine.ts; node executors are registered by type + version in lib/nodes/registry.ts.

Being honest about where it is

Sooket is early — this is v0.1.1. A couple of things worth knowing before you wire it into anything serious:

• Security model is deliberate, not accidental. The management API has no per-user login and binds to 127.0.0.1 only. To expose it, set a SOOKET_AUTH_TOKEN shared secret or front it with an authenticating reverse proxy + TLS. Don't just widen the bind address and walk away.
• It adds to request latency, because it is the request. That's the trade-off of inline execution — worth it for guard/redact/cache logic, something to measure for hot paths.
• Per-node reference docs and examples are still being written. ## License

Source-available under the Functional Source License, Version 1.1, MIT Future License (FSL-1.1-MIT): free to use, modify, and self-host for any purpose except offering it as a competing commercial product — and each release automatically becomes MIT-licensed two years after it ships.

Try it / tell me where it breaks

npx sooket

Repo, docs, and architecture notes: github.com/danilopatrial/sooket

danilopatrial / sooket

Visual canvas for API orchestration. Design middleware flows between your services, transform payloads, and ship to edge runtime.

Sooket

Build API middleware on a canvas — and run it inline in the request path.

Sooket is a visual canvas for building the logic that sits between a caller and your API — rate limiting, auth checks, PII redaction, caching, LLM calls request/response shaping — without writing a service to host it. You drag nodes connect them, and expose the pipeline as a single HTTP endpoint. Every request runs through the graph synchronously and gets a response back.

Why

Every API eventually needs a layer of glue in front of it: throttle abusive callers, strip PII before it hits a third party, cache expensive responses validate a token, fan a request out to an LLM. Today that glue is either hand-written middleware you have to build, test, and deploy, or it lives in an automation tool like n8n/Zapier — which run asynchronously, after the fact, and can't shape…

View on GitHub

If you build something with it — or if it falls over on your setup — I'd genuinely like to hear about it in the comments. The "inline middleware canvas" space is pretty empty, and I'm figuring out the sharp edges in the open.