Content Intake
Medusa has two content intake systems that share the ContentIntake model as their entry point. Each ContentIntake record has a type enum — either onix or import — which determines which processing pipeline handles its data. Both systems ultimately send content to Farfalla for ingestion.
The ONIX Intake system receives content from distribution partners via SFTP/S3 using the industry-standard ONIX XML format. The Content Import system provides a browser-based dashboard where tenants upload spreadsheets and content files directly. Despite their different input methods, they share infrastructure, status patterns, and the same goal: getting content into Farfalla.
System Comparison
| Aspect | ONIX Intake | Content Import |
|---|---|---|
| Source | SFTP/S3 from distribution partners | Browser upload by tenant admins |
| Content format | ONIX XML standard | Spreadsheets (XLSX/XLS/CSV) + files |
| File delivery | Partners push to monitored locations | Admins upload via presigned S3 URLs |
| Processing model | Event-driven (file detected → parse → process) | User-initiated (upload → validate → batch) |
| API endpoint | Internal-only Farfalla endpoints | Public /api/v3/content/bulk |
| Update tracking | Yes — detects inserts vs updates | No — always creates new records |
| Automation level | Fully automated (continuous monitoring) | Manual (user triggers each import) |
| Dashboard | Nova admin interface | Livewire tenant-facing dashboard |
| Error granularity | OnixIssue with multiple ignore reasons | ImportRecord with ignore_reason enum |
| Multi-tenant publishing | Can publish to multiple tenants / marketplace | Single tenant per import |
Model Equivalences
| ONIX Intake | Content Import | Role |
|---|---|---|
OnixFile | Import | Top-level processing unit (file or session) |
OnixEvent | ImportRecord | Individual content item to process (processing log) |
OnixIssue | ImportProduct | Unique product entity, one per external_id per team |
| (N/A) | ImportFile | Uploaded content file tracking (Import only) |
Shared Status Lifecycle
Both systems use the same status progression for their processing units:
draft → discovered → on-queue → done
↘ failed
- draft: Initial state — files being uploaded or metadata being prepared (Content Import only)
- discovered: Record parsed and ready for processing
- on-queue: Dispatched to the queue for API submission
- done: Successfully ingested by Farfalla
- failed: Processing failed (with categorized error reason)
The ImportStatus enum uses these values directly. The ONIX system uses equivalent status constants on its models. ONIX skips draft since file discovery is automated.
Shared Infrastructure
| Component | How It's Shared |
|---|---|
ContentIntake model | Both systems create records with their respective type value |
| S3 bucket | Same intake-s3 disk; different key prefixes per system |
| Farfalla API credentials | Stored on ContentIntake and used by both processing pipelines |
| Cache-based retry | Both use Laravel Cache for tracking retry attempts on server errors |
Loggable trait | Both Import and ONIX models use the same logging trait for traceability |
| Team scoping | Both filter all queries by team_id for multi-tenant isolation |
Further Reading
- ONIX Intake: ONIX Intake section — ONIX standard, file processing, partner integration
- Content Import: Content Import section — Dashboard, spreadsheet formats, batch processing