Data Delivery Models
🚚 Data Delivery Models
This page describes the supported data delivery models for sharing data with Fyre.
Fyre is designed to be flexible and compatible with different partner setups. Multiple delivery models are supported to accommodate technical constraints, existing architectures, and operational preferences.
Regardless of the chosen model, all delivered data follows the same ingestion and processing pipeline once received.
📋 Overview
Partners can deliver data to Fyre using one of the following models:
🔌 API-based delivery
📁 File-based delivery
🔄 Reverse integration (optional)
The difference between these models lies in how data is transferred to Fyre, not in how it is processed afterward.
For most partners, API-based delivery using standardized formats is the recommended approach.
🔌 API-Based Delivery (Recommended)
API-based delivery is the preferred data delivery model.
In this model, partners actively send data to Fyre by making authenticated API requests. This approach provides the highest level of control, predictability, and scalability.
API-based delivery works well when:
Transactional data can be accessed programmatically
Partners can push data outbound
Daily or ongoing data delivery is required
The same API can be used for:
Sample data during the preparation phase
Historical data backfills
Ongoing daily production delivery
Aligning API payloads with the Standardized Transactional Format is strongly recommended to simplify onboarding and long-term maintenance.
📁 File-Based Delivery
File-based delivery is supported for partners that:
Already generate scheduled data exports
Cannot deliver data directly via API
In this model, transactional data is delivered as files and stored for later processing.
File delivery is asynchronous and does not involve immediate validation.
Partner Sends Files to Fyre
Partners may generate export files and deliver them directly to Fyre.
This may include:
Uploading files to a designated storage location
Delivering files via secure transfer mechanisms
This option works well when partners already have reliable export jobs in place.
Fyre Retrieves Files from Partner Storage
In some cases, partners maintain transactional exports in their own cloud storage systems.
Fyre can be granted read-only access to retrieve files on a scheduled basis.
This approach works well when:
Exports already exist
Storage access is simpler than API integration
File structures remain stable over time
Supported File Formats
Common supported formats include:
CSV
JSON
Parquet
ndJSON
Existing export formats can usually be reused during onboarding. While standardized formats are preferred, Fyre can adapt to alternative structures when required.
🔄 Reverse Integration (Optional)
In specific cases, Fyre can connect directly to a partner’s API and retrieve data on a scheduled basis.
This model is typically used when:
The partner cannot adapt their delivery process
Outbound data delivery is restricted
Read-only access is preferred
Existing APIs already expose the required data
When reverse integration is used, partners must provide:
API documentation
Access constraints
Operational details
Reverse integration is fully supported but generally less reliable than push-based delivery, especially when POS systems are on-premise or rely on local infrastructure.
For this reason, it is considered a fallback option rather than a primary integration model.
⚙️ Data Handling Behavior
Regardless of the delivery model, data ingestion and processing are performed asynchronously.
Once received:
Data is stored
It is later processed as part of the ingestion pipeline
Validation, enrichment, and aggregation do not occur at delivery time.
This architecture allows Fyre to:
Handle large volumes of data efficiently
Support bulk deliveries and historical backfills
Apply consistent processing rules across all delivery models
Partners should ensure that delivered data is complete and consistent before submission.
🧭 Choosing the Right Model
While several delivery models are supported, most partners are encouraged to use:
API-based delivery with standardized formats
Alternative options such as file-based delivery or reverse integration remain available when technical or operational constraints apply.
The final delivery model is agreed during onboarding and may evolve over time if needed.
Last updated