The 26.7 release brings streamlined Archtics configuration, more reliable season and KPI reporting, improved settlement filtering, and expanded developer resources and Order API data. These updates help sales, marketing, ticketing operations, and data teams work more efficiently across FEVO.
Want to get the latest best practices, highlights, and success stories?
Sign up for the FEVO Academy Newsletter for all things product! Emails are delivered once weekly.
β Highlights
TM Archtics Enhancements: Organization admins can set defaults for Archtics Other Info fields and manage approved Comp Names centrally. This reduces repetitive entry, improves consistency, and helps keep ticketing records accurate. Read more in Inventory & Integrations.
Offers Dashboard & Full-Year Seasons: Offers Dashboard filters and display preferences now persist across sessions, browsers, and devices, while season definitions provide contiguous 12-month coverage without offseason gaps. Sales and operations teams can return to a consistent reporting view and reliably filter events across the full season. Read more in FEVO Enterprise.
Settlement Reporting Improvements: Settlement Reports now include Incomm and Costco Marketplace as Offer Type filters, making it easier to reconcile distribution channels, review partner settlements, and investigate transactions. Read more in Data & Reporting.
Developer Documentation & Order API: FEVO V2 API documentation is now available directly in Enterprise, and the Order API includes additional fields for event details, fees, ticketing-system reconciliation, and referral tracking. Developers and data teams can build and maintain integrations with less manual work. Read more in Data & Reporting.
π FEVO Enterprise
Add-On Controls β Vendor Agreements, Minimum Quantities, and Custom Donations
What's New
The centralized add-on flow now supports three new controls that give teams more flexibility when building offers:
Vendor Agreement assignment β Add-ons can now be linked to a Vendor Agreement directly from the Attributes tab. Admins select the appropriate agreement from a dropdown; Sales roles see the assigned agreement in read-only mode. If no agreement is set, the system defaults to "Add-On Fees."
Automatically Add to Cart with minimum quantity β When a minimum is configured (either "Match Ticket Quantity" or a specific number), you can turn on "Automatically Add to Cart." This pre-loads the add-on at the required quantity when the buyer reaches the add-on step and prevents checkout if the quantity drops below the minimum.
Open-dollar donation amounts β Donation-type add-ons now support buyer-entered amounts at checkout. Operators set a maximum (up to $100,000) and an optional suggested amount. The buyer types in their own dollar value, and the cart enforces the max in real time.
Additionally, hub-managed add-ons now display Name and Description as read-only on the offer-level Edit drawer. A banner directs users to the Add-Ons hub to make changes β preventing accidental edits when an add-on is shared across multiple offers.
Common use cases
Fundraising campaigns: Attach a Donation add-on and let fans choose how much to contribute at checkout, with a max cap set by your operations team.
Required promotional items: Set a minimum quantity and turn on "Automatically Add to Cart" so every buyer receives the required merchandise (e.g., 2 rally towels per order) without needing to manually select it.
Match ticket quantity: Use the "Match Ticket Quantity" minimum so the add-on count always equals the number of tickets in the cart β useful for per-seat items like food vouchers or parking passes.
Revenue allocation clarity: Assign the correct Vendor Agreement up front so settlement reports reflect the intended revenue split from day one.
Multi-offer add-ons: When a parking or merchandise add-on is shared across several offers, the locked Name/Description prevents one team from accidentally renaming it for everyone.
Where to configure
Vendor Agreement: Offer β Add-On β Attributes tab (Admin role required)
Automatically Add to Cart: Offer β Add-On β Inventory tab β Minimum section
Donation open-dollar amount: Create a Donation-type add-on β set Maximum Amount (and optional Suggested Amount)
Name/Description edits for hub add-ons: Add-Ons hub (not the offer-level drawer)
Add-On Inventory Display & One-Donation-Per-Offer Limit
What's New
Two changes improve how add-ons display and validate in the centralized add-on flow:
Open Inventory now shows "β" instead of "0" β The Qty column in the add-on table previously displayed
0for Open Inventory add-ons (where quantity isn't tracked). This incorrectly implied the item was sold out. Open Inventory add-ons now display a dash (β) to clearly indicate that quantity is unlimited and not being tracked.Only one Donation add-on per offer β The system now prevents teams from attaching more than one open-dollar Donation add-on to the same offer. If a donation add-on is already attached, additional donation options are disabled in the "Select Existing Add-On" modal with a tooltip: "Only one donation can be added per offer." This matches the behavior of the legacy flow and prevents invalid configurations from reaching buyers.
Common use cases
Open-inventory parking or merchandise: Staff reviewing an add-on table can immediately distinguish an open-inventory parking pass (showing "β") from an item that has genuinely sold out (showing "0").
Fundraising offer setup: An operator adding a donation add-on to a new offer will see remaining donation options disabled, preventing accidental double-donations that could confuse buyers at checkout.
Multi-offer add-on audits: When reviewing add-on status across several offers, the dash vs. zero distinction makes it fast to identify which items track inventory and which don't β no need to click into each one.
Please note: The one-donation limit applies going forward only. Existing offers that already have multiple donation add-ons attached continue to function as-is.
New Offers Dashboard β Persistent Filter Preferences
What's New
The new Offers Dashboard now saves all your filter and display preferences on the server. Previously, some settings were stored in your browser's local storage β meaning they would reset when you cleared your cache, switched devices, or used a different browser. The display metric toggle (Revenue / Tickets Sold / Orders) didn't persist at all and reset to Revenue on every login.
Now, every filter selection is saved automatically to your account the moment you change it β no "Save" button needed. Your preferences are:
Stored per user, per organization
Available from any browser or device
Retained across logouts, cache clears, and device switches
Filters that now persist
Date range type (Order Date vs. Event Date)
Date range values (start and end dates)
Venue / Organization filter
Display metric toggle (Revenue / Tickets Sold / Orders)
Offers table sort column and direction
Table page size (rows per page)
Table search text
Common use cases
Sales leaders reviewing regional performance: Set your venue, date range, and metric to Revenue once β the next time you log in (even from a different laptop), your view is exactly how you left it.
Multi-device workflows: Start reviewing the dashboard on your desktop, continue on your tablet at a meeting β same filters, same view.
Operations managers tracking ticket volume: Toggle to "Tickets Sold" and filter to a specific date range. The dashboard remembers your setup through cache clears and browser updates.
Independent user workspaces: Each user's filter preferences are completely separate β one person's changes never affect another user's view.
Where to find it
Open the Offers Dashboard. Any filter, sort, or metric change you make is automatically saved. No configuration or setup is required.
Full-Year Season Definitions β No More Offseason Gaps
What's New
Season date ranges are now contiguous across the full year. Previously, there was a gap between the end of one season and the start of the next β events or offers falling in that gap had no season assignment, which caused the Season filter and Offers Dashboard to behave unpredictably.
Now, each league's season is defined as a full 12-month window of contiguous months, starting on the 1st of the configured start month and running through the last day of the month immediately before the next season begins. There is always exactly one active season for any given date β no undefined "offseason" periods.
The system labels seasons automatically:
Current Season β the season window containing today's date
Last Season β the season window immediately before the current one
Upcoming Season β the season window immediately after the current one
This applies across all surfaces that use the Season filter: Event Hub, Offers Dashboard, Report User Dashboard, and Opt-In Dashboard.
Common use cases
NFL-style seasons that cross calendar years: A league with a June start month defines the 2026 season as 6/1/2026β5/31/2027. A February 2027 event correctly resolves to the 2026 Current Season β no manual adjustment needed.
January events no longer "disappear": Previously, a January event could fall into an undefined gap between two season windows. Now it is always assigned to exactly one season and shows up in the correct filter view.
Consistent Offers reporting: Sales and ops teams filtering the KPI Dashboard by "Current Season" will see all events within the defined 12-month window β including future events that haven't occurred yet but belong to the current season.
Multi-league organizations: Each league maintains its own season start month. An organization with NFL (June start) and NBA (October start) teams sees accurate, independent season assignments for both.
Please note: Season boundaries use full-month precision β a season always starts on the 1st of its start month and ends on the last day of the preceding month. Existing season data has been automatically migrated to the contiguous format.
π« TM Archtics
Archtics Other Info Defaults & Org-Level Comp Names
What's New
Two changes reduce manual data entry and improve Archtics data quality for Ticketmaster clients:
Default values for Other Info Attribute Fields β Org admins can now assign a default value to any enabled Other Info field (standard or custom). The available default options are: Group Name, Offer Name, Reason for Offer, or FEVO Order Number. When a rep creates a new offer, mapped fields auto-populate with the configured value β no manual entry needed.
Critically, these defaults also write back to Archtics on every transaction. Whatever value is active on the offer at the time of purchase (whether the org default or a manual override) is pushed back to the corresponding Archtics Other Info field automatically. This keeps Archtics in sync as the system of record without requiring reps to re-enter data on the Archtics side.
Org-level Comp Name management β Comp Names can now be stored and managed at the org level, following the same pattern as Sales Source. Admins create and maintain a list of approved Comp Names once; reps then select from that list when creating or editing an inventory set. Values are scoped per org and persisted on the inventory set record.
Common use cases
Eliminating repetitive data entry: A ticketing ops team sets "Group Name" and "Reason for Offer" as defaults. Every new offer auto-fills these fields β reps no longer type the same values manually for each offer.
Keeping Archtics accurate without extra work: When a buyer completes a transaction, the FEVO Order Number writes back to Archtics Other Info automatically. The box office team sees the confirmation number in Archtics without anyone copying it over.
Standardizing Comp Names across reps: An org creates an approved list of Comp Names (e.g., "Community Partner," "Sponsor Guest," "VIP Client"). Reps pick from the list instead of free-typing, eliminating typos and inconsistencies that make Archtics reporting unreliable.
Overriding defaults for special cases: A rep creating a one-off promotional offer can change the auto-populated Reason for Offer to something specific. The override is what writes back to Archtics β the system always respects the value active at the time of transaction.
Where to configure
Other Info defaults: Org-level Archtics settings β enable an attribute field β assign a Default Value from the dropdown
Comp Names: Org-level Archtics settings β Comp Names section (create, edit, manage list)
Inventory set assignment: Inventory Management β Create or Edit an inventory set β select a Comp Name from the dropdown
Please note: Default values apply to new offers going forward. Existing offers retain their current field values and are not retroactively updated. If an org renames a group or offer after a default is set, new offers pick up the current name β existing offers are unaffected.
π Data & Reporting
Settlement Report β Incomm & Costco Marketplace Filters
What's New
The Settlement Report now includes two additional Offer Type filter options: Incomm (BJβs, H-E-B, Sam's Club) and Costco Marketplace. Previously, the Offer Type dropdown only displayed "Standard" and "Costco," which meant teams couldn't isolate transactions from Incomm or Costco Marketplace offers without exporting and manually sorting data.
Now, when you open Reports β Settlements β Filters β Offer Type, you'll see all four options:
Standard
Costco
Incomm
Costco Marketplace
Selecting any filter returns only the matching settlement transactions β no export or manual filtering needed.
Common use cases
Marketplace revenue reconciliation: A venue running offers through both Costco Warehouse and Costco Marketplace can now pull settlement data for each channel independently to reconcile revenue by distribution partner.
Incomm partner reporting: Teams distributing offers through Incomm can filter directly to those transactions when preparing partner settlement summaries or verifying payout accuracy.
Channel performance comparison: Sales or finance teams can quickly compare settlement totals across Standard, Costco, Incomm, and Costco Marketplace to understand which distribution channels are driving volume.
Audit and dispute resolution: When a transaction is in question, ops teams can narrow down to the exact offer type and locate the relevant settlement record without scrolling through unrelated data.
Where to find it
Reports β Settlements β Filters (side sheet) β Offer Type dropdown. Select one or more offer types to filter the report.
Developer Documentation β Available Directly in Enterprise
What's New
FEVO V2 API documentation is now accessible as a dedicated section within Enterprise. Previously, developers working with the FEVO API had to reference documentation hosted outside the platform β switching between tabs, bookmarks, or external links to find endpoint details while configuring integrations.
Now, the full API documentation lives where partners already manage their FEVO work. No context switching, no hunting for the right link.
Common use cases
Partner technical onboarding: A new integration partner can go from account setup to reading endpoint documentation without ever leaving Enterprise β reducing onboarding friction and support questions.
Mid-build reference checks: A developer in the middle of building a connection doesn't need to switch to an external doc site to confirm a parameter or response format. The docs are one click away from the configuration they're actively working on.
Sales engineering demos: When walking a prospect through FEVO's integration capabilities, the technical team can show live documentation alongside the product β reinforcing that FEVO is developer-ready.
Reduced support load: Self-serve documentation inside the platform means fewer "where do I find the API docs?" or "what's the endpoint for X?" questions hitting your team.
Where to find it
Open Enterprise β Developer Documentation section. The full FEVO V2 API reference is available there.
Order API β New Fields for Reporting, Reconciliation, and Customer Lookup
What's New
The FEVO V2 Order API now returns six additional fields that were previously only available in the legacy v1 endpoint:
Field | What it provides |
| Seating section for the order |
| Fees the buyer paid at time of purchase |
| Date of the event associated with the order |
| The order ID in the connected ticketing system (e.g., Archtics, SeatGeek) |
| The customer ID in the connected ticketing system |
| The referral or share code used on the order |
These fields are returned automatically β no configuration change is needed. Any existing integration using the Order endpoint will see the new fields in the response.
Common use cases
Downstream order reporting: A data team can now build reports that include event date, section, and fees paid β without joining data from a separate source or requesting a manual export.
Ticketing system reconciliation: Use
eventServiceOrderIDandeventServiceCustomerIDto match FEVO orders back to records in Archtics or SeatGeek automatically, eliminating manual cross-referencing.Fee transparency for finance:
paid_fees_at_checkoutgives finance teams the exact fee amount per order for settlement verification and revenue reconciliation.Referral program tracking: The
referral_codefield lets marketing teams attribute orders to specific share links or campaigns through the API β useful for measuring group-buying and social distribution performance.Event-level segmentation: Filter or group API results by
Event_dateto analyze order volume, fees, or referral activity on a per-event basis.
