Data Delivery Models

This page describes the supported data delivery models for sharing data with Fyre.

Fyre is designed to be flexible and work 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 most control, predictability, and scalability over time.

API-based delivery works well when:

• Transactional data can be accessed programmatically

• Partners can push data outbound

• Ongoing daily delivery is required

The same API can be used during the preparation phase for sample data delivery and later for historical backfills and daily production data.

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 exports or 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.

File-based delivery can be implemented in several ways.

Partner sends files to Fyre

Partners may generate export files and deliver them directly to Fyre. This can include uploading files to a designated storage location or delivering them through agreed 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 these files on a scheduled basis.

This approach is suitable when:

• Exports already exist

• Storage access is easier than API integration

• File structures are stable over time

Supported file formats

Common file formats include, but are not limited to:

• 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 integrate directly with 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, additional alignment is required. Partners must provide API documentation, access constraints, and operational details.

Reverse integration is fully supported but is generally less reliable than push-based delivery, especially when POS systems are deployed on-premise or depend 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.

Data is stored upon receipt and processed later as part of the ingestion pipeline. Validation, enrichment, and aggregation do not occur at delivery time.

This design allows Fyre to:

• Handle large volumes of data efficiently

• Support bulk deliveries and historical backfills

• Apply consistent processing rules across all delivery methods

Partners should ensure that delivered data is complete and consistent before submission.

Choosing the right model

While multiple delivery models are supported, most partners are encouraged to use API-based delivery with standardized formats.

File-based delivery and reverse integration are suitable alternatives when technical or operational constraints apply. The final delivery model is agreed during onboarding and can evolve over time if needed.