Transactional Data Requirements

💳 Transactional Data Requirements

This page describes the requirements for sharing sample transactional data during the preparation phase of the integration.

After the outlet list has been shared and reviewed, Fyre requires approximately one month of transactional data for the same outlets. This step is mandatory for all integration models and is used for validation and alignment, not production ingestion.


📥 Initial Transactional Data Submission

Before any production or historical data is enabled, share a sample of transactional data (~1 month) covering the approved outlets.

Purpose of this sample:

  • ✅ Validate structure and identifier alignment

  • ⚙️ Assess data quality and consistency

  • 🏷️ Enrich and complete outlet profiles previously shared

⚠️ Transactional data should only reference outlets included in the approved outlet list.


🤔 Why This Data is Required

  • The outlet list provides static info (name, address)

  • Transactional data shows how outlets operate in practice

  • Enables accurate market segmentation and comparable analytics

Analyzing real sales data helps Fyre derive outlet characteristics not visible from metadata alone.


📊 What One Month of Data Allows

A ~1-month sample enables Fyre to analyze consumption patterns and derive key outlet characteristics:

  • 🏨 Venue type – inferred from products sold and timing

  • 📈 Outlet size – based on sales volume

  • 🍽️ Food vs beverage ratio, alcohol vs non-alcohol

  • 💵 Typical average check size

  • 🔍 Activity indicators – how established and active the outlet is

These insights enrich the standardized outlet profiles.


🗂️ Market Segmentation & Enrichment

  • Outlets are classified using Fyre’s four-level market segment hierarchy

  • Transactional line items are interpreted and normalized so that:

    • Products with different naming conventions can be compared

    • Categories are applied consistently

    • Brands and brand owners are identified where possible

Normalization ensures reliable category, brand, and owner-level analytics.


📏 Scope of the Sample Data

The transactional data sample should:

  • Cover approximately one full calendar month

  • Include only approved outlets

  • Represent real production data

  • Avoid test or partial datasets


✅ Required Fields

Each transactional record must include:

  • Outlet reference matching the outlet list identifier

  • Unique order ID

  • Unique order-item ID

  • Product ID and product name

  • Quantity and price

  • At least one reliable timestamp

These fields are required to link transactions, deduplicate records, and support enrichment/aggregation.


Optional but strongly recommended:

  • Category IDs & names

  • Tax amounts and rates

  • Currency

  • Number of guests

  • Cost / purchase price

  • Item relationships (combos, modifiers, toppings)

  • Additional timestamps

Including these improves normalization, segmentation, and revenue estimation.


🔑 Identifier Rules

  • Outlet references must match the outlet list identifiers exactly

  • Order IDs must be unique per outlet

  • Order-item IDs must be unique per outlet

  • Identifiers must remain stable over time


⏱️ Timestamp Expectations

  • Mandatory: Order creation timestamp – when the order was created/opened

    • Must be clear, consistent, single timezone

  • Optional (recommended): Payment timestamp – when the order was paid/closed

    • Helps with service duration, correct business day assignment, time-based analysis

  • Multiple timestamps must be clearly named, consistent format and timezone

  • Standardized transactional format expects ISO 8601 in UTC (if used)


📄 Standardized Transactional Format

  • Fyre provides a standardized format to simplify onboarding & maintenance

  • Optional but strongly recommended

  • Can be reused for initial sample, historical backfills, and daily delivery

  • Field-level definitions and examples are in Standardized Transactional Format section


🚚 How to Deliver the Sample Data

This page defines what data is required, not delivery method.

Delivery options are covered in:

  • Data Delivery Models

  • API-Based Delivery

  • File-Based Delivery

  • Reverse Integration

Partners should review these sections to choose the model that fits their setup.


✅ What Happens After Submission

  1. Fyre performs a structured review of the sample data

  2. Checks include:

    • Structural completeness

    • Correct use of identifiers & timestamps

    • Consistency with outlet list

    • Initial quality checks for enrichment and segmentation

  3. Fyre shares actionable feedback if adjustments are needed

Once approved:

  • Final integration model is confirmed

  • API access enabled (if applicable)

  • Historical data delivery scheduled

  • Daily production data flows activated


🏁 Next Step

To align with Fyre’s preferred structure, see Standardized Transactional Format for field-level definitions and examples.

Last updated