Reverse Integration

This page describes reverse integration, where Fyre retrieves transactional data directly from a partner’s systems instead of the partner actively delivering data.

Reverse integration is supported in specific scenarios where outbound data delivery is not feasible due to technical, security, or operational constraints. It is considered an alternative integration model, rather than the default.

When reverse integration is used

Reverse integration is typically used when:

• Partners cannot push data outbound from their systems

• Outbound data delivery is restricted by internal security policies

• Read-only access is required or preferred

• Transactional data is already exposed through existing APIs

In these cases, Fyre adapts to the partner’s existing API rather than requiring changes to the partner’s delivery pipeline.

How reverse integration works

In a reverse integration setup, Fyre connects to the partner’s API and retrieves transactional data on an agreed schedule.

Data retrieved from the partner API is stored as received and processed at a later stage as part of Fyre’s ingestion pipeline. Validation, enrichment, normalization, and aggregation are not performed at the time of retrieval.

This asynchronous approach allows Fyre to:

• Handle large volumes of data

• Support bulk retrievals and historical backfills

• Apply consistent processing rules across all delivery models

Reverse integration follows the same preparation flow as other integrations, including outlet list review and sample data validation.

Completed transactions and refunds

Fyre’s analytics and enrichment processes are based on completed transactions only.

When transactional data is retrieved via reverse integration, Fyre expects to receive:

• Completed or finalized orders

• Line items that represent actual sales

Transactions that were refunded, voided, cancelled, or reversed should ideally be excluded at the source.

If the partner’s API supports filtering, Fyre should be able to:

• Retrieve only completed or paid orders

• Exclude fully refunded or cancelled transactions

• Exclude returned items or reversed line items

If such filtering is not available, the partner must provide sufficient information to allow Fyre to identify and exclude these cases during processing. This may include:

• Order or item status fields

• Refund or cancellation indicators

• Negative quantities or negative prices

• Explicit refund or return records

• Links between original transactions and refund entries

Clear documentation of how refunds, returns, and cancellations are represented in the API is required to ensure accurate filtering during transformation.

Identifier and timestamp expectations

Reverse integration relies heavily on identifier stability and timestamp consistency.

• Outlet references must match the identifiers used in the outlet list

• Order identifiers must be unique per outlet

• Order-item identifiers must be unique per outlet

• Identifiers must remain stable over time

Each transactional record must include at least one timestamp representing when the order was created or opened in the POS system. Additional timestamps may be provided if available.

These rules are essential to support correct deduplication, enrichment, and aggregation when data is retrieved incrementally.

Information required from the partner

Reverse integration requires additional technical alignment compared to push-based delivery.

Partners must provide:

• Complete API documentation for the relevant endpoints

• Authentication and authorization details

• Rate limits and throttling rules

• Retry behavior and idempotency expectations

• IP restrictions or allowlisting requirements

• Country- or market-specific access limitations

• Known data availability delays or latency constraints

• Planned maintenance windows and breaking-change policies

This information is required to ensure data can be retrieved reliably and safely.

Operational considerations

Reverse integration introduces dependencies that are outside of Fyre’s direct control.

This model may be less reliable when:

• POS systems are deployed on-premise

• Connectivity depends on local infrastructure

• APIs are not designed for sustained or high-volume extraction

• Availability varies by outlet, country, or time of day

In such cases, intermittent connectivity or API instability can directly impact data completeness and timeliness.

For this reason, reverse integration is generally treated as a fallback option, rather than a primary integration model.

Choosing reverse integration

Reverse integration is a valid and supported approach when push-based delivery is not possible.

However, when partners can actively deliver data using API-based or file-based delivery, those models are typically preferred due to clearer operational boundaries and higher reliability.

The final integration model is agreed during onboarding based on technical feasibility and long-term sustainability.