Any website or file, searchable in one call

Aman Bhakar — Fri, 11 Sep 2026 06:45:08 +0000

Your AI feature is only as good as what you feed it.

And what you have to feed it is a docs site that renders in JavaScript, 400 scanned PDFs, and a help centre nobody has exported since 2023.

So you write a scraper. Then a PDF parser. Then OCR. Then you're picking a chunking strategy, an embedding model, a vector store. Three weeks gone and the feature still isn't built.

That's the part we deleted. 👇

curl -X POST https://crawl.sarv.com/api/kb/$KB_ID/jobs \
  -H "x-api-key: $SARVCRAWL_KEY" \
  -d '{"type":"crawl","url":"https://docs.yoursite.com"}'

One call in. Clean markdown out — indexed, chunked, embedded, searchable by keyword and by meaning. No pipeline. No vector database to run.

🚀 Try it free → crawl.sarv.com

1 billion tokens on sign-up. No card.

🧰 What it does


🕷️	Crawl a whole site — JS-rendered pages included	docs →
📄	Scrape one page to clean markdown	docs →
🗺️	Map every URL before you commit to a crawl	docs →
📎	Upload PDF, DOCX, XLSX, PPTX, CSV, images — OCR included	docs →
🔄	Monitor a source and re-crawl only what changed	docs →
🔍	Search by keyword, or by meaning	docs →

🔌 Where it plugs in


🤖	MCP — crawl and search from Claude Code, Cursor, VS Code	docs →
🟢	Node SDK	docs →
🐍	Python SDK	docs →
⌨️	CLI	docs →
🔗	n8n nodes	docs →

🔎 Every answer traces back to a page you can open

The console isn't a wrapper on the API. It's where you check the crawl, read the exact chunks your model will be handed, and find the bad conversion before your users do.

Most tools give you a vector and a shrug. This one gives you a score for the conversion and a link to the source page.

📖 Read the API docs

🏠 Or self-host it

Open source, Apache-2.0, one .env and one docker compose up -d. Cloud when you want it to be someone else's problem, self-hosted when it can't leave your network — same API either way.

🚀 crawl.sarv.com — 1 billion tokens free

What are you trying to make searchable? Tell me in the comments — I'm curious which sources break it. 👇

FlowHub: I got tired of rewriting SMS/OAuth/webhook code every time we switched providers, so I split it into 16 npm packages and one all-in-one package

Aman Bhakar — Thu, 23 Jul 2026 07:30:00 +0000

Every backend I've worked on ends up with the same mess: Twilio calls in one file, Stripe-style OAuth in another, S3 upload logic somewhere else — each with its own error shape, its own (usually missing) retry logic, and no consistent way to know "this thing happened" across the app. Swapping Twilio for MSG91 means hunting down every call site.

So I built Flow Hub — 16 small, independently-installable @flowhub/* packages that put one typed interface in front of each concern (SMS, email, OAuth, storage, OTP, webhooks, queue, cache), backed by a shared event bus. Provider swaps become a register() call, not a refactor.

Before / after

Hand-rolled multi-provider SMS with retry + fallback — the code most teams actually ship:

\ts async function sendOtpSms(to: string, body: string) { for (const attempt of [1, 2, 3]) { try { await twilioClient.messages.create({ to, body, from: TWILIO_FROM }); return; } catch { if (attempt === 3) { await msg91Client.send({ to, body }); // different call shape return; } await new Promise((r) => setTimeout(r, 200 * attempt)); } } } \\

With Flow Hub:

\`ts
import { SmsRegistry } from "@flowhub/sms";
import { retry } from "@flowhub/retry";

const sms = new SmsRegistry(app.events);
sms.register(twilioProvider);
sms.register(msg91Provider);

async function sendOtpSms(to: string, body: string) {
try {
await retry(() => sms.send("twilio", to, body), { attempts: 3, delayMs: 200, backoff: "exponential" });
} catch {
await sms.send("msg91", to, body);
}
}
`\

Same behavior, and app.events.on("sms.sent", ...) / sms.failed fire regardless of which provider handled it.

Try it in 60 seconds

Real terminal output, against what's actually published:

\`console
$ npm add -g @flowhub/cli
$ flowkit init my-app
create my-app/package.json
create my-app/index.js
create my-app/.gitignore

$ cd my-app && npm install && flowkit add twilio
update package.json (+@flowhub/sms)

$ npm install && npm start
FlowKit app ready
`\

What's in it

core — event bus, DI, plugin lifecycle
sms / email / oauth / storage / webhook / queue / cache — provider registries, each with typed register() + events
otp — generation/verification/expiry/cooldown
express / cli — route helpers and the flowkit scaffolding CLI
flowhub — a meta-package that re-exports all of the above in one npm install if you don't want to add them one at a time

All MIT-licensed, all on npm under @flowhub, source at github.com/gitaman69/flowhub.

The part I want to be honest about

Right after publishing, I went back and installed all 16 packages fresh from the registry (not the local workspace) and wrote a smoke test hitting every module's real behavior. Found a real bug: @flowhub/otp's resend-cooldown was tracked on the same object verify() deletes on success — so a successful verify silently reset the cooldown, letting generate() → verify() → generate() bypass the rate limit meant to throttle SMS/email sends. Fixed, tested, republished as 0.0.3. Change log's in the repo if you want the details.

Feedback, bug reports, and provider implementations (got MSG91, real GCS, real Mailgun?) welcome — that's what the CONTRIBUTING guide is for.

DEV Community: Aman Bhakar