Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/ItsJhonAlex/Ecommerce/llms.txt

Use this file to discover all available pages before exploring further.

The Avanzar product catalog is built around a core products table that stores identity, status, and stock. Pricing, images, and category memberships are each managed in dedicated satellite tables, keeping the core lean and making it straightforward to add a new currency or image without touching the product row itself. Every product exposes a URL-friendly slug that serves as its public identifier across storefront endpoints.

​
Product Fields

The products table contains the following columns:
ColumnTypeNotes
idUUIDPrimary key, generated by the database
slugtext (unique)URL-friendly identifier used in all public storefront endpoints
nametextDisplay name shown to customers
descriptiontext (nullable)Full product description; may be null for draft products
statusproduct_statusOne of draft, active, or archived — see below
stockQuantityinteger (default 0)Current units available; decremented at checkout, restored on cancellation
createdAttimestamptzRow creation timestamp
updatedAttimestamptzLast modification timestamp

​
Product Statuses

draft

The product is under construction and not visible in the public storefront. Use this state while filling in descriptions, uploading images, or setting prices.

active

The product is publicly visible and available for purchase. Only active products are returned by the storefront listing and detail endpoints.

archived

The product has been soft-deleted. It is hidden from the storefront and from the default admin listing. Archived products are never hard-deleted, preserving their data for historical order references.
Always prefer archiving over deleting a product. Hard-deleting a product sets order_items.productId to null (via ON DELETE SET NULL), which severs the link used for stock restoration on cancellation.

​
Multi-Currency Pricing

Prices live in a separate product_prices table so that a single product can be sold in multiple currencies without duplicating the product row. 
// Schema: product_prices
{
  id:          uuid,          // Primary key
  productId:   uuid,          // FK → products.id (CASCADE delete)
  currency:    text,          // ISO 4217 code, e.g. "USD" or "CUP"
  amountMinor: integer,       // Amount in the currency's smallest unit (cents)
}
// Unique constraint: (productId, currency)
Key rules:
  • Each product can have at most one price per currency, enforced by the unique constraint product_prices_product_currency_uq.
  • Amounts are stored in minor units (cents, centavos) as integers — never floating-point — to avoid rounding errors.
  • The currency field is a 3-character ISO 4217 string.
Example: A product priced at USD 29.99 is stored as amountMinor: 2999, currency: "USD". CUP 1500.00 would be stored as amountMinor: 150000, currency: "CUP". At checkout, the backend resolves the price for the requested currency server-side. If no price exists for the requested currency, checkout is rejected with error code PRICE_NOT_AVAILABLE.

​
Product Images

Images are stored in the product_images table with an explicit ordering position field:
ColumnTypeNotes
idUUIDPrimary key
productIdUUIDFK → products.id (CASCADE delete)
urltextAbsolute URL to the hosted image asset
alttext (nullable)Alternative text for accessibility
positioninteger (default 0)Sort order; position 0 is the primary image
All queries that return product images order results by position ASC. The primary (hero) image is always position: 0. When re-ordering images via the admin API, update the position values to reflect the desired sequence.

​
Categories

Categories are stored in the categories table and linked to products through the product_categories many-to-many join table. 
// categories — supports nested hierarchies via parentId
{
  id:       uuid,            // Primary key
  slug:     text (unique),   // URL-friendly identifier
  name:     text,            // Display name
  parentId: uuid (nullable), // Self-reference for subcategories (SET NULL on delete)
}

// product_categories — composite PK
{
  productId:  uuid,  // FK → products.id (CASCADE)
  categoryId: uuid,  // FK → categories.id (CASCADE)
}
Hierarchy: Categories support a single level of self-referencing via parentId. A category with parentId: null is a root category; any category with a non-null parentId is a subcategory. The public API returns a flat array of all categories — the client application is responsible for building the visual tree from parentId references. Linking products to categories: Use POST /api/v1/admin/products/:id/categories with a body of { "categoryId": "<uuid>" } to associate an existing category with a product. Use DELETE /api/v1/admin/products/:id/categories/:categoryId to remove a link.
Deleting a category cascades through product_categories to remove all product–category links for that category, but the products themselves are not affected. Products without any category simply appear uncategorised in the storefront.

Build docs developers (and LLMs) love

Get started for freeTalk to us