Advanced Wishlist & Registry

Paid pluginsize Mplanned, not built

Indicative price, not an offer: EUR 150-300/year or EUR 350 one-off

Generated from docs/plan/paid/advanced-wishlist-registry/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Basic wishlist exists but is underutilized. This feature adds gift registries (wedding, birthday), multi-list support, and sharing so customers can drive repeat visits and gift sales.

The problem

My customers want to create multiple wishlists (wedding registry, birthday list, general wishlist) and share them with friends. I need to turn wishlists into a sales channel.

What it does

• Multiple wishlists: customer can create and name wishlists (My Wishlist, Wedding Registry, Birthday)
• Registry types: generic wishlist, wedding registry (two-person), birthday registry (date-based)
• List metadata: customer can add list title, description, event date, share message
• Sharing: generate public share link (no auth required), trackable share token; show list to friend without login
• Guest purchases: friend can buy from list without creating account (guest checkout)
• Fulfillment tracking: mark item as ‘purchased by [name]’ so duplicates are prevented
• Admin: view all wishlists, see which items were purchased and by whom, support for gift registry reports
• API endpoints: CRUD wishlists, manage items, generate share link, track guest purchases

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Wishlist collaboration (multiple customers managing one list) — single owner per list
• Price tracking (notify when item goes on sale) — monitoring is out of scope
• Group gifting (pool money from multiple friends) — single-buyer checkout only

Data model

Update Wishlist entity: rename from simple one-per-customer to {id, customer_id, name, list_type (generic/wedding/birthday), description, event_date (nullable), share_token (unique), is_public, created_at}. New entity: WishlistItem {id, wishlist_id, product_id, quantity, purchased_by (nullable), purchased_at (nullable)}.

API

• POST /api/wishlists — create wishlist
• GET /api/wishlists — list customer’s wishlists
• GET /api/wishlists/:id — fetch wishlist detail
• PATCH /api/wishlists/:id — update wishlist
• POST /api/wishlists/:id/items — add item to wishlist
• DELETE /api/wishlists/:id/items/:product_id — remove item
• GET /api/wishlists/share/:token — fetch public wishlist (no auth)
• POST /api/wishlists/:id/mark-purchased — mark item as purchased by guest name

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Wishlist manager: list of customer wishlists, search by customer. View wishlist: items, which were purchased and by whom, share link and share date/count. Reports: total items on all wishlists, popular items on wishlists, registry conversion rate (wish → purchase).

The seam — why this is paid

Core owns the wishlist model, sharing mechanism, and REST API. Paid layer owns advanced analytics and marketing (retarget friends who saw a registry but didn’t buy, automatic reminder emails when items go on sale).

Paid business feature. Core provides basic wishlist; sharing, gift registries, and multi-list management are paid add-ons.

Dependencies

• Existing Wishlist entity (must be updated)
• Customer entity (already shipped)
• Public routing (share link must not require auth)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A customer can create a new wishlist named ‘Wedding Registry’ with description
• Customer adds 5 products to the wishlist
• Customer can generate a share link; link is unique and public (no login required)
• A friend follows share link, sees the registry items and descriptions
• Friend adds item to cart and checks out (guest checkout, no account needed)
• After purchase, item in the registry is marked ‘Purchased by [friend name]’ automatically
• Couple can view their registry and see which items were purchased and by whom

Risks

Share tokens must be unique and not guessable (UUID, not sequential). Public lists can be discovered via enumeration if token is weak (force UUID length). Marking items as purchased requires coordination (item added to cart, but hasn’t checked out yet; mark-purchased should be idempotent). Duplicate purchases can happen if two friends buy the same item simultaneously; ordering/reservation is not implemented in v1 (document as limitation).

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.