API-Based Delivery

This page describes API-based delivery, where partners send transactional data directly to Fyre using the Fyre API.

API-based delivery is the recommended integration model and represents the primary long-term approach for delivering transactional data to Fyre. It provides a clear contract, predictable behavior, and a stable foundation for ongoing data delivery.

When API-based delivery is used

API-based delivery is used when partners can actively send data from their systems and want a well-defined, programmatic integration.

The same API mechanism is used throughout the integration lifecycle, including:

• The initial one-month transactional data sample during preparation

• Historical transactional data, where applicable

• Ongoing daily production data delivery

No separate delivery model is required for different phases.

How API-based delivery works

In an API-based delivery setup, the partner sends transactional data to Fyre by making authenticated API requests.

Data received by the API is stored as received and processed asynchronously at a later stage as part of Fyre’s ingestion pipeline. Validation, enrichment, normalization, and aggregation do not occur at the time the request is received.

Partners should treat API delivery as an asynchronous operation and ensure that the data they submit is complete, correct, and final at the time of submission.

If data needs to be sent again for the same scope, it may be re-submitted. When the same dataset is sent again using the same identifying parameters (such as file name and purchase date), the newly submitted data replaces the previously stored data for that scope.

Data structure, identifiers, and timestamps

API-based delivery uses the Standardized Transactional Format as its canonical data structure.

This format defines:

• Required and optional fields

• Identifier conventions

• Timestamp expectations

• Order-item level granularity

Payloads sent to the API are expected to align with this format. The API does not redefine the structure; it enforces the contract described in Standardized Transactional Format.

In particular:

• Outlet references must match the approved outlet list

• Order identifiers must be unique per outlet

• Order-item identifiers must be unique per outlet

• Identifiers must remain stable over time

Each record must include the mandatory order creation timestamp defined in the standardized format.

Completed transactions only

Transactional data delivered via the API must include completed and finalized orders only.

The following must not be sent via the API:

• Cancelled or voided orders

• Fully refunded orders

• Partially refunded orders

• Returned items

• Reversal, correction, or compensating records

For API-based delivery, Fyre does not perform post-processing to remove refunds or corrections. Data received via the API is treated as authoritative input and processed as-is.

If completed transactions cannot be reliably isolated at source, API-based delivery is not suitable, and an alternative delivery model should be discussed.