Supplier Auto-Sync (EDI/API)

Paid pluginsize Lplanned, not built

Indicative price, not an offer: €49/mo; per-supplier setup, EDI/API sync, PO generation

Generated from docs/plan/paid/supplier-auto-sync/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid enterprise module that automatically syncs inventory with supplier APIs and EDI feeds, generates purchase orders, and tracks PO status. Eliminates manual reorder entry and reduces procurement delays. Critical for businesses with frequent reorders from repeat suppliers.

The problem

I submit reorders manually via email or supplier portal; it takes 30 min per order and errors happen. My suppliers have APIs or EDI feeds I could plug into. I need automated low-stock reordering that generates POs and tracks delivery.

What it does

• Supplier connection setup: URL, API key/EDI credentials, per-supplier config stored encrypted in plugin key-value store
• Sync schedule: daily, weekly, or on-demand trigger; run via scheduled job
• Low-stock trigger: product qty <= reorder_point for any product linked to supplier, auto-create PO
• EDI/API payload generation: format PO data as XML (EDI 850) or JSON per supplier spec
• PO creation: auto-generate purchase_order record, link to supplier, mark auto_generated=true
• Sync audit log: timestamp, supplier_id, record_count sent/received, status (success/failure), error_detail
• Error handling: if sync fails, log error and send alert; do NOT create duplicate PO on retry
• Idempotency: use supplier’s PO number or internal batch_id to prevent duplicate sends
• Supplier response status: if supplier API returns PO confirmation, store confirmation_number and confirmation_date
• Sync history viewer: UI showing all sync runs, status, record counts, errors

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.

• Full EDI standard implementation (850, 856, 810 cycles) — XML only; merchant provides supplier-specific mappings; ASN (Advanced Shipping Notice) is out of scope
• Payment processing or invoice automation — PO is generated; payment and invoice reconciliation are separate
• Multi-warehouse routing or source selection — MSI module handles fulfillment paths; sync is single-supplier, single-purchase order
• Supplier performance monitoring or scoring — logs are available; merchants do manual review and relationship management

Data model

New tables: supplier_connections (id, supplier_id, api_url, api_key_encrypted, sync_format enum(json, xml_edi), sync_schedule enum(daily, weekly, on_demand), last_synced_at, last_sync_status), sync_logs (id, supplier_id, sync_started_at, sync_completed_at, records_sent, records_received, status enum(success, failure, partial), error_detail), purchase_orders extended with supplier_id, auto_generated boolean, sync_batch_id, supplier_confirmation_number, supplier_confirmation_date.

API

• POST /api/suppliers/:id/connection
• PATCH /api/suppliers/:id/connection
• POST /api/suppliers/:id/sync-now
• GET /api/suppliers/:id/sync-history
• GET /api/sync-logs/:logId
• GET /api/purchase-orders?auto_generated=true
• POST /api/purchase-orders/:id/mark-confirmed

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

Admin

Supplier connection editor with API URL and key input, sync schedule selector, manual sync button, sync history table with status/error detail, PO viewer showing auto_generated flag and confirmation_number, sync failure alert settings (Slack, email).

The seam — why this is paid

Core owns the purchase-order interface. Paid owns EDI compliance, supplier-specific API maintenance (format changes, rate limits), auto-trigger algorithms, and the SLA for sync uptime and error recovery.

Support commitment: EDI compliance, supplier API maintenance, PO audit trail

Dependencies

• product module (SKU lookup)
• supplier module (credentials, API keys)
• inventory module (reorder_point check)
• purchase order module (PO generation)
• webhook system (sync failure alerts)

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.

• POST connection encrypts api_key before storage
• Sync trigger fires only if any product for that supplier has qty <= reorder_point
• Generated PO has auto_generated=true and sync_batch_id matching sync_log.id
• Duplicate sync within same batch (retry) does not create second PO (idempotency key prevents)
• Sync failure logs error_detail and sends webhook alert
• Supplier API response confirmation_number stored in purchase_order.supplier_confirmation_number
• Sync history visible to staff; errors are detailed enough for troubleshooting

Risks

API key exposure in logs or backups (must never log plaintext); supplier API downtime blocks all reorders (no fallback); PO duplication if idempotency fails; rate-limiting from supplier API causes timeout (need backoff/retry); supplier format change breaks production sync (must version API calls).

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.