July 13, 2026 5 min read TypeScript fork

wapp api

Abstract

CodeChat - WhatsApp Api

Here's a concise, professional technical briefing for the wapp-api repository, written in the style of a senior AI engineer consultant report.

The Problem

This repository contains a WhatsApp API implementation built on top of the Baileys library, exposed as a RESTful service. It is untested, has committed secrets, and suffers from circular import dependencies that make changes high-risk. The codebase is large and densely coupled, with 32 of 62 analyzed modules in circular imports and duplicated logic across 53 files.

What This Does

The project exposes WhatsApp functionality via a Node.js REST/WS API. Execution starts at src/main.ts:42 (bootstrap), which reaches 39 functions and is the single entry point. From there, control flows through AppModule → onModuleInit, which triggers instance creation and network connectivity to WhatsApp via axios. The heaviest dependency is src/whatsapp/services/whatsapp.service.ts, which defines the core message and media types, makes outbound network calls, and is called from 6 other files. The import graph has 32 modules in circular dependencies, centered on src/app.module (15 importers, 30 imported, instability 0.67) and src/whatsapp/services/whatsapp.service (3 importers, 18 imported, instability 0.86). Eighty repeated 6-line blocks across 53 files indicate duplicated boilerplate that should be extracted. The committed .env.dev contains generated credentials (SESSION_HTTP_SECRET, AUTHENTICATION_GLOBAL_AUTH_TOKEN, AUTHENTICATION_JWT_SECRET) that are loaded at boot, making them active working credentials in any clone.

How It Is Wired

Execution starts at bootstrap in src/main.ts:42, which instantiates AppModule. AppModule imports 15 other modules and is itself imported by 30, placing it at the center of a circular dependency cycle. Routing is handled by routerPath in src/validate/router.validate.ts, called from 7 places and invoked 18 times from ChatRouter, 11 from InstanceRouter, 9 from GroupRouter, and 9 from MessageRouter. The webhook handler sendDataWebhook is called from 17 places and funnels data from inbound WhatsApp events. Database reads and writes pass through src/repository/repository.service.ts, which reads/writes the DB and is called from 2 files. Outbound network calls are made via axios from the onModuleInit lifecycle, traced as bootstrap -> AppModule -> onModuleInit [network via axios.post]. The provider session manager at src/provider/sessions.ts also makes outbound calls and is initialized from 12 files.

How To Use It

Setup: Clone the repo with git clone https://github.com/moses-y/wapp-api. Run npm install (preferred) or npm install --force. Start PostgreSQL via docker-compose -f postgres/docker-compose.yaml up -d. Copy .env.dev to .env and rotate all committed credentials before running.

Configuration: Required env vars are in .env.dev. Key vars include DATABASE_URL (PostgreSQL connection string), SESSION_HTTP_SECRET, AUTHENTICATION_GLOBAL_AUTH_TOKEN, and AUTHENTICATION_JWT_SECRET. The Prisma schema lives in prisma/schema.prisma; run npx prisma migrate dev in development or npx prisma migrate deploy in production.

Running it: The entry point is src/main.ts. Start with npm run start:dev (or the equivalent script in package.json). The server bootstraps, initializes the WhatsApp client connection, and listens on the configured port.

Real-World Use

A team needs a backend service that receives WhatsApp messages, routes them to internal workflows, and sends replies via the WhatsApp Business API. This repo provides a ready-made REST/WS surface for that, with instance management, webhook handling, and group/chat operations. However, the lack of tests and the committed secrets mean it should not be used in production without a security review and test coverage.

Code Health & Issues

The static analysis found 46 findings (34 high, 12 medium, 0 low), 6 distinct kinds:

[HIGH/soundness] Import cycle member x32 — files: src/app.module.ts, src/exceptions/index.ts, src/repository/repository.service.ts. Participates in circular import dependency. Break the cycle by extracting shared types or inverting a dependency.
[MEDIUM/cognitive_load] High branching density x5 — files: src/config/env.config.ts, src/whatsapp/controllers/sendMessage.controller.ts, src/whatsapp/controllers/views.controller.ts. 69 branch points over 190 lines. Decompose decision-heavy logic.
[MEDIUM/cognitive_load] Deep nesting — file: src/validate/validate.schema.ts. Max indentation depth 6. Flatten with guard clauses.
[HIGH/cognitive_load] Oversized file x2 — files: src/validate/validate.schema.ts, src/whatsapp/services/whatsapp.service.ts. 712 code lines each. Split into cohesive units.
[MEDIUM/clarity] Hub module x5 — files: src/app.module.ts, src/config/env.config.ts, src/config/logger.config.ts. 15 modules depend on these; churn here has high-blast-radius. Keep stable and small.
[HIGH/clarity] Duplicated code blocks — files: src/app.module.ts, src/middle/logger.middle.ts, src/config/env.config.ts, src/config/error.config.ts. 80 repeated 6-line blocks across 53 files. Extract shared helpers.

SDLC observations (from repo structure, not the measured block):

No test files detected — untested code paths repository-wide.
Dependencies declared without a lockfile — non-reproducible builds (package.json).
Secret-shaped paths present; .env.dev is committed and loaded at boot.
CI: GitHub Actions present; Dockerfile and Docker Compose present.
License: GPL-3.0 present.

The Bottom Line

This is a functional WhatsApp API wrapper with good infrastructure (Docker, Prisma, CI) but significant maintainability and security debt. The circular imports, duplicated boilerplate, and committed credentials make it unsuitable for production as-is. It can be salvaged by rotating secrets, adding a lockfile, extracting the duplicated config logic, and writing minimal test coverage per entry point. Best suited for greenfield projects that can afford the refactor time, or for teams needing a quick PoC who will address the technical debt early.

Analysis generated by static pipeline: import graph, call edges, file responsibilities, and health findings are deterministic outputs from the codebase under review. No hype, no fluff, no invented edges.

What the analyser found

Deployment readiness

4/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

109 files

TypeScript55
YAML11
SQL10
JSON5
Markdown5
JavaScript2

ReactDocker

Module dependencies

The 10 most depended-upon modules of 60, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_src_app_module["app.module"] n1_src_config_env_config["env.config"] n2_src_exceptions_index["index"] n3_src_config_logger_config["logger.config"] n4_rc_whatsapp_dto_instance_dto["instance.dto"] n5_epository_repository_service["repository.service"] n6_app_services_monitor_service["monitor.service"] n7_src_validate_router_validate["router.validate"] n8_src_whatsapp_dto_webhook_dto["webhook.dto"] n9_src_provider_sessions["sessions"] n0_src_app_module --> n3_src_config_logger_config n0_src_app_module --> n5_epository_repository_service n0_src_app_module --> n1_src_config_env_config n0_src_app_module --> n6_app_services_monitor_service n0_src_app_module --> n9_src_provider_sessions n3_src_config_logger_config --> n1_src_config_env_config n9_src_provider_sessions --> n1_src_config_env_config n9_src_provider_sessions --> n3_src_config_logger_config n5_epository_repository_service --> n8_src_whatsapp_dto_webhook_dto n5_epository_repository_service --> n2_src_exceptions_index n5_epository_repository_service --> n3_src_config_logger_config n5_epository_repository_service --> n1_src_config_env_config n7_src_validate_router_validate --> n4_rc_whatsapp_dto_instance_dto n7_src_validate_router_validate --> n2_src_exceptions_index n7_src_validate_router_validate --> n3_src_config_logger_config n7_src_validate_router_validate --> n1_src_config_env_config n6_app_services_monitor_service --> n3_src_config_logger_config n6_app_services_monitor_service --> n1_src_config_env_config classDef cyc stroke:#ef4444,stroke-width:2px; class n0_src_app_module,n2_src_exceptions_index,n5_epository_repository_service,n6_app_services_monitor_service,n7_src_validate_router_validate cyc;

Findings

MediumNo test files detected - untested code paths repository-wide
LowDependencies declared without a lockfile - non-reproducible builds package.json
LowSecret-shaped paths present; the code-health audit confirms or clears them .env.dev

Open in Code Brain → See its neighbourhood →

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high5

medium6

low1

Rotate the credentials in the committed environment filecritical3 occurrences

.env.dev

SESSION_HTTP_SECRET, AUTHENTICATION_GLOBAL_AUTH_TOKEN, AUTHENTICATION_JWT_SECRET hold generated values

These values are loaded by the application at boot, so a generated value here is a working credential for something that runs.

Fix: Rotate each named credential, remove the file from the index, and replace it with a keys-only example.

Pin third-party GitHub Actions to a commit SHAhigh4 occurrences

.github/workflows

docker/setup-qemu-action@v3, docker/setup-buildx-action@v3, docker/login-action@v3, docker/build-push-action@v6

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Add a test suite; this repository has nonehigh60 occurrences

60 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Commit a lockfile beside the manifesthigh

package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Move the database password out of the connection stringhigh

.env.dev

postgres URL with an inline password, host is remote

A connection string is a complete credential including the endpoint, so unlike a bare password it is directly usable against a reachable database.

Fix: Reference the password from the environment and rotate the database user.

Remove the committed .env and rotate what it holdshigh

.env.dev

A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.

Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.

Declare least-privilege permissions for GITHUB_TOKENmedium2 occurrences

.github/workflows/docker-image.yml

2 workflow(s) declare no permissions, 1 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

Dockerfile

node:24-bullseye-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Add a pre-commit secret gatemedium

a secret-shaped file is tracked and no repo-level gate is visible

Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.

Fix: Add a pre-commit hook scanning staged content, and enable push protection.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

1 further finding(s) are listed in the full report.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.

View on GitHub All Projects