E-FACTS — E-receipt management companyE-FACTS — E-receipt management company
Engineering

Architecture

System boundaries across iOS, backend, website, and docs

Architecture

E-FACTS is a multi-repo product system: consumer clients talk to a shopper API; marketing and docs are separate Next.js frontends with their own deploy and auth stories.

Boundaries

BoundaryRule
Consumer data planeiOS ↔ backend APIs (JWT). Source of truth is the API + PostgreSQL.
MarketingPublic site; may deep-link into app / retailer flows — not the receipt vault.
Internal docsCompany handbook; lightweight cookie gate; not shopper JWT.
Jobs / asyncRedis / BullMQ workers for background work — keep request paths thin.

Request path (shopper)

sequenceDiagram
  participant App as iOS app
  participant API as Backend API
  participant DB as PostgreSQL
  App->>API: Auth (email/password or Google id_token)
  API-->>App: access JWT (+ refresh rotation)
  App->>API: Authenticated shopper calls
  API->>DB: Read/write receipts, warranties, offers
  API-->>App: snake_case JSON (money in cents)

Major capabilities

CapabilityNotes
AuthRegister / login / refresh / logout; Google via POST /api/v1/shopper/auth/google
ReceiptsStructured receipts + line items
WarrantiesWarranty records tied to items / purchases
Wallet bindSensitive identity bind (UCI / last4) validated server-side
StreamsSSE shopper stream where enabled (GET /api/v1/shopper/stream)
OffersRetailer offers + redemption (product priority band P3)

iOS modular layout (current app)

Typical folders under the SwiftUI app:

AreaResponsibility
App/EFactsApp, RootTabView
Core/Routing/AppRouter, AppTab
Features/Home, Bills, Analysis, Offers
Models/Receipts, offers, supporting types
Services/AppSession, ShopperAPIClient, Keychain

Docs site layout (efacts-dev)

PathRole
content/docs/MDX handbook
src/app/App Router routes
src/proxy.tsDocs auth gate + content negotiation
docs/Design.mdCanonical design source
public/brand/Logo assets

On this page