API-Based Delivery
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 entire integration lifecycle, including:
The initial one-month transactional data sample during the preparation phase
Historical transactional data, when applicable
Ongoing daily production data delivery
No separate delivery model is required for different phases of the integration.
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.
At the time the request is received, the API does not perform:
Validation
Enrichment
Normalization
Aggregation
These processes occur later during ingestion.
Partners should therefore treat API delivery as an asynchronous operation and ensure that the data they submit is:
Complete
Correct
Final at the time of submission
Resubmitting data
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.
This mechanism allows partners to correct or refresh previously delivered datasets when necessary.
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 the Standardized Transactional Format documentation.
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 also 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.
Last updated