Back to Project

Sellavie.ai Technical Case Study

Multi-tenant AI social sales backend that automates Instagram, Facebook, and WhatsApp conversations and connects them to order, invoice, and payment workflows through a single FastAPI service.

Live siteProject page

Tech At A Glance

Python 3.11FastAPISQLite (runtime path)React 18 + ViteMeta Graph APIsOpenAI / Anthropic / GroqPaystack / Flutterwave / StripeNginx reverse proxyJWT + refresh rotationFernet encryption

Problem

Small and mid-size online businesses lose revenue when social DMs are answered late, handoffs are inconsistent, and payment follow-through is manual. They need one system that can route conversations, keep tenant data isolated, and execute commerce side effects safely.

Architecture

  • Backend is a FastAPI monolith handling auth, tenant management, webhooks, AI orchestration, and commerce APIs.
  • Tenant isolation is enforced with `business_id` row scoping and owner/team access checks.
  • Webhook entrypoint verifies signatures and dispatches Instagram, Facebook, and WhatsApp events.
  • AI pipeline loads tenant context and runs provider fallback when preferred providers fail.
  • Internal action tags trigger server-side workflows for handoff, checkout, invoice, and payment state updates.
  • Nginx serves the SPA and proxies `/api` to FastAPI; runtime persistence uses SQLite with WAL mode.

Key Engineering Highlights

  • Implemented tenant-scoped auth with JWT access/refresh rotation, hashed refresh tokens, and optional TOTP 2FA.
  • Built deterministic tenant routing for external webhooks using layered integration identifier matching.
  • Designed state-machine-style action routing by parsing internal tags from AI output and stripping them from customer text.
  • Integrated payment workflows through verified webhook callbacks and order/invoice/transaction synchronization.
  • Added non-blocking task execution for notifications and side work with async tasks and lightweight worker threads.
  • Hardened reliability with provider failover, duplicate-order guards, payload limits, and per-IP rate limiting.

Security & Privacy

  • HMAC verification for Meta and payment webhooks before processing side effects.
  • Password hashing with bcrypt and signed JWT tokens with refresh rotation.
  • Optional TOTP 2FA for business accounts.
  • Fernet-encrypted storage and masked API responses for sensitive payment configuration fields.
  • Request hardening with scanner blocking, body-size limits, and rate-limit buckets.
  • Consent/export/deletion endpoints and Meta deauthorize/data-deletion callbacks for lifecycle compliance.

Architecture Diagrams

Mermaid runtime rendering is not configured in this portfolio codebase, so the diagrams below are static SVG assets derived from the Mermaid definitions in the Sellavie docs.

Sellavie architecture diagram showing browser, webhook source, FastAPI service, SQLite, and external providers.
System component architecture: client edge, API runtime, data layer, and provider integrations.
Webhook sequence diagram showing DM ingestion, signature verification, tenant routing, AI generation, and reply dispatch.
Inbound DM flow: webhook verification, tenant context loading, state-machine action parsing, and reply.

Build Timeline

  • Defined core multi-tenant schema and access model (`users`, `businesses`, `integrations`, `conversations`, `orders`, `invoices`).
  • Shipped webhook ingestion and channel-specific handlers for Instagram, Facebook, and WhatsApp.
  • Built tenant-scoped AI context loading and provider failover orchestration.
  • Added commerce workflows: purchase detection, checkout sessions, invoice generation, and payment reconciliation.
  • Implemented analytics, activity logging, moderation/handoff routing, and compliance endpoints.

Future Work

  • Move process-local rate limiting and token revocation to shared Redis infrastructure.
  • Standardize runtime on PostgreSQL path and introduce explicit migration tooling.
  • Add a durable queue for outbound messaging and invoice/email jobs.
  • Split the backend into bounded modules to reduce coupling and improve testability.