At FLYR, we work to ensure a reliable and accurate integration between StayNTouch and FLYR. That said, certain limitations in how StayNTouch structures and exposes data via its API can result in instances where reported figures between the two systems don't fully align.
If any of these discrepancies were identified during your onboarding process, our team would have proactively flagged and discussed them with you.
Below is a detailed overview of known data gaps, their causes, and suggested workarounds.
Note: These scenarios have been raised directly with StayNTouch. Any improvements made to the integration as a result of those discussions will be reflected in this article as they become available.
1. Account postings are not traceable
Description
Revenue posted directly to accounts in StayNTouch is not accessible via the API in a way that allows FLYR to trace or attribute it. Because there is no booking-level reference attached to these postings, the revenue cannot be surfaced in FLYR reporting.
Suggested workaround
Post revenue directly to the booking rather than to an account. This ensures FLYR can retrieve and correctly attribute the revenue.
2. Manual transfer of postings between bookings
Description
When postings are manually moved from one booking to another in StayNTouch, these transfers are not tracked in a way the API can expose. As a result, FLYR may reflect the revenue on the original booking — even after it has been moved — which can lead to duplicated historical revenue appearing in reporting.
Suggested workaround
Avoid manually transferring postings between bookings.
3. Groups and allotments: release date behavior
Description
StayNTouch currently exposes both groups and allotments through the same API endpoint, which means FLYR handles them identically. Both groups and allotments are affected by the inputted release date:
Before the release date: The full room block is treated as confirmed in FLYR, provided the block status deducts from inventory.
After the release date: Only rooms that have been picked up are treated as confirmed. Any rooms that were not picked up are released and, will appear as cancelled in FLYR.
This difference in behavior can cause discrepancies in how group and allotment blocks are reflected in FLYR — particularly for blocks where pickup is still in progress but the release date has passed.
Suggested workaround
Set the release date to the last day of the series. This prevents non-picked-up rooms from being prematurely released or cancelled in FLYR before the block period has concluded, giving your team time to manage pickup without data inconsistencies appearing in reporting.
Summary
FLYR's integration with StayNTouch captures the majority of operational and financial data accurately. The scenarios above reflect specific API limitations within StayNTouch that can cause persistent discrepancies. Following the suggested workarounds will significantly reduce data inconsistencies between the two systems.
If you have any questions or encounter a discrepancy not listed here, please check out this article on Data Validation and reach out to our support team. We're here to keep your reporting as accurate as possible.