Building a WhatsApp Automation SaaS? 5 Security Checks First

A product manager who couldn't code shipped a WhatsApp automation SaaS in about 60 days with Claude Code. That product is WhatsScale. Its founder, Mahidhar, wrote up the build on Indie Hackers: 134 commits, 60 days, and $0 MRR with 5 beta users at the time.

Today WhatsScale has a public pricing page. Paid plans start at $5 a month per connected number. That makes it a good example of a whole app category. If you are building something like it, this post covers the security holes this type of app often ships with. It is not a review of WhatsScale. I have not tested it and make no claims about its code.

Building an app like WhatsScale?

Here is what this kind of app does. A small business connects its WhatsApp number. Then it sends order confirmations, abandoned-cart reminders and shipping updates automatically. It triggers them from its store, from Make.com or Zapier, or from a REST API.

The Indie Hackers post says the goal was to use personal WhatsApp numbers and skip the approval and cost of the official WhatsApp Business API. It started as an MVP for a Fantasy Premier League group. Zapier turned down his first application. Make.com approved 13 templates, which became a distribution channel.

The pricing page explains the product in plain numbers:

• Free: $0, 1 WhatsApp session, 100 texts a month. Limited API access, no webhooks.
• Starter: $5 a month per session, up to 5 sessions. Full API access (26 endpoints), webhooks, media and scheduled messages. 14-day trial, no card.
• Growth: $29 a month or $299 a year. In late September 2026 it was listed as coming from October 1.
• Team and Enterprise: coming soon or custom.

A "session" is one connected WhatsApp number. That word is the key to the security picture. In this app type, a connected number usually means your server holds a live login to that WhatsApp account.

The 5 holes this app type usually ships with

When you vibe-code an app like this, the AI will make it work fast. It won't always make it safe. These are the gaps I would look for first in any WhatsApp automation API.

1. API keys stored in plain text. If your database leaks, every customer's key leaks with it. Store only a hash of each key, and show the real key once at creation.

2. No ownership check on session IDs. A route like /api/sessions/:id/messages must check that the session belongs to the caller. Otherwise customer A can send from customer B's number. This bug is called IDOR (insecure direct object reference). See API route IDOR.

3. Session data stored unencrypted. The saved login state for a WhatsApp session is as sensitive as a password. Encrypt it at rest, and keep the encryption key outside the database.

4. Webhook URLs nobody checks. Customers give you a URL, and your server calls it. Without checks, someone can point it at your internal network. That is SSRF (server-side request forgery). Also sign the webhooks you send, so customers can verify they came from you. See SSRF from unvalidated fetch.

5. No sending limits. Unlimited messages invite spam. Spam gets numbers reported and restricted by WhatsApp. That hurts your customer, not the spammer. Rate-limit per session and per API key. See API rate limiting.

One more thing is not code at all. Automating a personal WhatsApp number is outside the official Business API. Tell your customers plainly what that means for their number.

BEFORE and AFTER: holes 1 and 2 in one route

Here is a typical first draft of a "send message" route. It finds the API key by comparing plain text. Then it loads the session by ID alone.

// BEFORE: plain-text key, and no ownership check on the session
const apiKey = await db.apiKey.findFirst({
  where: { key: req.headers.get("x-api-key") ?? "" },
});
if (!apiKey) return new Response("Unauthorized", { status: 401 });

const session = await db.waSession.findUnique({ where: { id: sessionId } });

Here is the fixed version. The key is hashed, revoked keys are rejected, and the session must belong to the key's workspace.

// AFTER: hashed key + session scoped to the caller's workspace
import { createHash } from "node:crypto";

const raw = req.headers.get("x-api-key") ?? "";
const hash = createHash("sha256").update(raw).digest("hex");

const apiKey = await db.apiKey.findUnique({ where: { hash } });
if (!apiKey || apiKey.revokedAt) {
  return new Response("Unauthorized", { status: 401 });
}

const session = await db.waSession.findFirst({
  where: { id: sessionId, workspaceId: apiKey.workspaceId },
});
if (!session) return new Response("Not found", { status: 404 });

Why a plain SHA-256 here and not bcrypt? API keys are long random strings, not human passwords. A fast hash is standard for them. Passwords still need a slow hash like bcrypt or Argon2.

The curl test

Test this on your own app, on your own machine. Create two accounts, A and B. Take a session ID from account B. Then call the API with account A's key.

curl -i -X POST http://localhost:3000/api/sessions/SESSION_ID_FROM_ACCOUNT_B/messages \
  -H "x-api-key: API_KEY_FROM_ACCOUNT_A" \
  -H "content-type: application/json" \
  -d '{"to":"15550001111","text":"ownership test"}'

You want a 404. A 200 means one customer can send messages from another customer's number. Fix that before anything else.

If you vibe-code this

A short checklist for any WhatsApp or SMS automation API:

1. Hash API keys. Show them once. Let users revoke them.
2. Scope every session query to the caller's workspace. Test it with the curl above.
3. Encrypt saved session data at rest. See environment variables for where the key should live.
4. Validate customer webhook URLs, and sign the webhooks you send.
5. Rate-limit per session and per key.

For a broader walk-through, read the vibe coding security guide and secure authentication for vibe coders.

Building a messaging API and want a second pair of eyes before customers connect their numbers? I review vibe-coded apps before launch. Email [email protected].

Key takeaway

A non-developer can ship a WhatsApp automation API in 60 days with Claude Code. WhatsScale shows that. But this app type holds live logins to other people's phone numbers. Hash the keys, scope every session to its owner, and limit sending before you take your first paying customer.

More case studies: Vibe-coded apps making money. Security basics: Vibe coding security guide.

Sources

• Indie Hackers: From PM who couldn't code to shipping a SaaS in 60 days using Claude Code (Jan 26, 2026)
• WhatsScale homepage
• WhatsScale pricing