BullAPI is a multi-tenant B2B SaaS platform for high-volume WhatsApp communication, CRM workflows, and sales automation.
Built on the official Meta WhatsApp Cloud API (WABA), the platform combines event-driven processing, distributed queues, real-time synchronization, and tenant-aware access control to support traffic-intensive sales operations.
The system was designed around three core requirements: fast webhook ingestion, reliable asynchronous processing, and strict workspace isolation.
-
Event-Driven Architecture — Webhook ingestion is decoupled from downstream processing through Redis and BullMQ, keeping the API responsive during traffic spikes.
-
High-Throughput Processing — The platform has been stress-tested at 35,000 requests per minute, with the architecture designed to scale processing horizontally through distributed workers.
-
Production Reliability — Asynchronous workers, retry policies, exponential backoff, and workload isolation reduce the impact of temporary database or external-service failures.
-
Multi-Tenant SaaS Design — Workspace-level isolation and role-based authorization protect tenant boundaries across CRM data, users, integrations, and automation workflows.
-
Real-Time Collaboration — Socket.IO synchronizes conversations, leads, and CRM state between backend services and connected frontend clients.
-
Security-Oriented Data Handling — Sensitive message data can be protected with AES-256 encryption at rest, while authentication and authorization are enforced through JWT-based access control.
BullAPI separates event ingestion from event processing, allowing each layer to scale and fail independently.
NestJS webhook handlers receive events from the Meta WhatsApp Cloud API and immediately offload processing to Redis-backed queues.
This keeps the public ingestion path lightweight and maintains webhook response times below approximately 50 ms under expected operating conditions.
Expensive work such as persistence, automation, synchronization, and external integrations happens asynchronously.
BullMQ workers consume queued events and handle:
- message persistence;
- CRM updates;
- automation rules;
- external webhook delivery;
- synchronization events;
- retryable background operations.
Retries use exponential backoff so temporary downstream failures do not block webhook ingestion or cause aggressive retry loops.
A Socket.IO gateway provides bidirectional communication between backend services and the Next.js frontend.
Tenant-scoped channels propagate events such as:
- incoming messages;
- lead updates;
- pipeline changes;
- assignments;
- automation results.
This keeps connected CRM clients synchronized without relying on aggressive polling.
BullAPI includes an outbound webhook layer for integrations with:
- n8n;
- Zapier;
- custom HTTP endpoints.
This allows customers to extend BullAPI workflows without requiring every business integration to be implemented directly inside the core platform.
BullAPI integrates directly with Meta's official WhatsApp Business infrastructure.
The platform supports:
- inbound and outbound messages;
- webhook events;
- message templates;
- business account workflows;
- automation triggers.
Using the official API avoids dependence on browser-based WhatsApp automation and provides a more stable integration model for business messaging.
A drag-and-drop sales pipeline supports high lead volumes and enables teams to organize conversations across customizable CRM stages.
Permissions are defined across workspace roles such as:
- Owner
- Manager
- Agent
The platform also supports plan-based feature gating across SaaS subscription tiers.
Internal automation supports:
- keyword-based routing;
- event-driven actions;
- CRM workflow triggers;
- outbound webhooks;
- low-code integrations with external automation platforms.
The platform includes support for USDT and BTC payment flows as an additional settlement option for international B2B customers.
BullAPI uses explicit workspace identifiers throughout tenant-scoped operations.
Queries and business operations enforce workspace ownership before accessing or modifying:
- contacts;
- conversations;
- pipelines;
- users;
- automations;
- integration settings.
The architecture is designed so that tenant context is explicitly propagated rather than inferred from client input.
Authentication is implemented using:
- JWT access tokens;
- Passport.js;
- bcrypt password hashing.
Application-level authorization combines:
- workspace membership;
- role-based permissions;
- plan-based feature access.
Sensitive message data can be encrypted at rest using AES-256 application-level encryption.
Prisma transactions are used for operations where multiple related database changes must remain consistent, particularly across CRM and lead-management workflows.
BullAPI was successfully stress-tested at approximately 35,000 requests per minute.
The test validated the architecture's ability to keep webhook ingestion responsive while transferring heavier workloads to asynchronous workers.
During pilot workloads, BullAPI achieved approximately 99.9% observed availability.
The reliability strategy combines:
- asynchronous processing;
- Redis-backed queues;
- retries with exponential backoff;
- workload decoupling;
- transactional persistence;
- distributed workers;
- dependency isolation.
The architecture prioritizes graceful degradation over tightly coupling webhook availability to downstream services.
Webhook endpoints should acknowledge external events quickly.
Business processing therefore happens outside the request lifecycle whenever possible.
Traffic spikes are absorbed by Redis and BullMQ instead of being passed directly to PostgreSQL or downstream integrations.
This allows processing throughput to scale independently from ingestion throughput.
Workspace context is carried through application operations rather than relying solely on frontend-provided identifiers.
Operations that depend on external services are designed around retries and exponential backoff instead of assuming those dependencies are always available.
Socket.IO handles client synchronization while PostgreSQL remains responsible for durable application state.
Outbound webhooks provide an extensibility layer instead of introducing tight coupling between the core platform and every third-party service.
| Area | Technologies |
|---|---|
| Language | TypeScript |
| Backend | Node.js, NestJS |
| Frontend | React, Next.js |
| Database | PostgreSQL |
| ORM | Prisma |
| Queue & Messaging | Redis, BullMQ |
| Real-Time | Socket.IO |
| Authentication | Passport.js, JWT, bcrypt |
| Automation | Webhooks, n8n, Zapier |
| Infrastructure | Docker, Kubernetes |
| Architecture | Event-Driven, Multi-Tenant SaaS, Asynchronous Processing |
BullAPI demonstrates hands-on engineering experience across:
- Backend Engineering
- Event-Driven Architecture
- Distributed Systems
- Asynchronous Processing
- High-Throughput APIs
- Redis & BullMQ
- Multi-Tenant SaaS Architecture
- Real-Time Systems
- API Integrations
- Authentication & Authorization
- Database Consistency
- Performance Testing
- Production Reliability
BullAPI is a private commercial product, so the production source code is not publicly available.
This repository documents the system's architecture, engineering decisions, scalability strategy, and production characteristics without exposing proprietary implementation details.
BullAPI was designed and developed end-to-end, covering:
System Design · Backend · Frontend · Database Architecture · Async Processing · Real-Time Communication · Integrations · Security · Infrastructure
The project reflects the engineering decisions involved in building and operating a production-oriented, multi-tenant SaaS platform rather than only implementing isolated application features.