Getting Started

How It Works & Architecture

Understanding the shape of the system makes installation and configuration far easier. At a high level there is one backend and four clients that all communicate with it over a REST API.

The big picture

            ┌───────────────────────────────────────────────┐
            │           Laravel backend (your server)        │
            │   Admin panel · Storefront · REST API · Jobs   │
            │                  MySQL database                │
            └───────────────────────────────────────────────┘
                 ▲           ▲            ▲            ▲
                 │ HTTPS     │ HTTPS      │ HTTPS      │ HTTPS
        ┌────────┴───┐ ┌─────┴─────┐ ┌────┴─────┐ ┌────┴──────┐
        │  Website   │ │ Customer  │ │ Delivery │ │  Seller   │
        │ (browser)  │ │   app     │ │   app    │ │   app     │
        └────────────┘ └───────────┘ └──────────┘ └───────────┘

The backend hosts the public storefront, the admin panel, the JSON API the apps call, and the background jobs that send notifications and process payouts.
Each mobile app is a thin client: it has no database of its own. It calls the API, shows the results, and caches a little data locally.
Every app is pointed at your backend by setting one API base URL (see Configuration Model).

The API

The apps talk to versioned endpoints under /api, each with its own prefix:

Customer app

/api/v1_6/customer/…

Delivery app

/api/v1/partner/…

Seller app

/api/v2/seller/…

Website

Server-rendered via Inertia.js (no separate API prefix)

On first launch each app calls a settings endpoint (e.g. fetchCustomerSettings) that returns your branding, currency, enabled login methods, modules and more — so most of what the app shows is controlled from your admin panel, not baked into the app.

A typical order, end to end

Browse & cart The customer opens the app, picks a store/module, adds products to the cart.
Checkout They choose an address and a payment method. Online payments run through a gateway (e.g. Razorpay); cash-on-delivery is also supported.
Order created The backend records the order and notifies the seller. A push notification (FCM) is sent to the Seller app.
Seller accepts & packs The seller confirms the order in the Seller app (or web panel) and marks it ready.
Delivery assigned A delivery partner receives an offer in the Delivery app, accepts, and navigates to pickup.
Live tracking The customer watches the rider move on a map in real time.
Delivered & settled The partner marks delivery complete, cash is recorded if applicable, and wallet/commission/cashback are updated by background jobs.

⚙️

Steps that "happen automatically" — push notifications, cashback, loyalty points, subscriptions, payouts — are run by the scheduler & queue worker. If those aren't set up, orders still work but those automations won't fire. See Cron & Queue Workers.

Where settings live

Almost all configuration is stored in the database and edited from the admin panel — payment keys, SMS gateways, branding, currency, taxes, languages, delivery zones, module toggles, and the values the apps read at startup. You rarely edit source code. The few exceptions (each app's API URL, Firebase config and Maps key) are explained in the Configuration Model.

👉

Next: Configuration Model — exactly what you set in the admin panel vs. in each app's source.