CSV Export

Free — GPL coresize Mplanned, not built

Generated from docs/plan/core/csv-export/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants export products, customers, and orders as CSV files for analysis in spreadsheets, sharing with accountants, or data import to other systems. CSV files are formatted with headers and one row per record. Core owns the export logic; this is infrastructure, not a paid feature.

The problem

Merchants need to analyze data in spreadsheets or share with accountants. CSV export is more accessible than JSON for non-technical users.

What it does

• Product CSV: SKU, name, description, price (in EUR or selected currency), inventory, category, tags
• Customer CSV: name, email, address, phone, order count, lifetime value, account date
• Order CSV: order ID, date, customer email, items (list), total, payment status, shipping address
• Number formatting: prices are exported as integers (minor units); decimals not used
• Date formatting: ISO 8601 (YYYY-MM-DD)
• Character encoding: UTF-8 (supports international characters)
• Export filtering: admin can filter by date range (e.g., orders from 2026-08-01 to 2026-08-31)
• Download: CSV files are ready to download immediately after export

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.

• Real-time exports: export is point-in-time only.
• Scheduled exports: we provide on-demand only (scheduled exports are separate, optional feature).
• Excel format: CSV only; Excel requires separate feature (xls-export).

Data model

New document: csv_export_record { exportId, timestamp, type (products, customers, orders), rowCount, fileSize, status (completed, failed) }.

API

• POST /api/export/csv/products -> CSV file (download immediately)
• POST /api/export/csv/customers -> CSV file
• POST /api/export/csv/orders { from, to } -> CSV file
• GET /api/export/csv/history (admin only) -> list of past exports

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

Admin

Admin sees: export buttons (products, customers, orders), date range picker for orders, download links, export history.

The seam — why this is core

Core owns CSV export logic and formatting. No paid seam; this is infrastructure.

Core owns the interface + honest CSV exporter; data portability is infrastructure, not a support commitment or credential.

Dependencies

• product subsystem (existing)
• customer subsystem (existing)
• order subsystem (existing)

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.

• Admin clicks ‘Export products’; CSV file downloads with headers and 1000 rows
• CSV headers are: SKU, name, description, price, inventory, category, tags
• Prices in CSV are integers (e.g., 1050 for 10.50 EUR); no decimal points
• Dates in CSV are ISO 8601 (2026-09-03)
• Admin selects date range 2026-08-01 to 2026-08-31; only orders from that period are exported
• CSV is valid (parseable by Excel, Google Sheets, Python pandas)
• UTF-8 encoding preserves special characters (é, ü, ñ)
• Export history shows 3 past exports; admin can re-download

Risks

If prices are exported as floats, spreadsheet software rounds them and data is corrupted. If CSV is not UTF-8 encoded, non-ASCII characters show as garbage. If headers are missing, third-party tools cannot parse file. If date format is inconsistent (some rows MM/DD, others DD/MM), parsing fails. If row count is inaccurate (off by one), user doesn’t notice missing data until later. If customer email is exposed without consent, GDPR is violated.

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.