Punchh Platform Release Notes - 21 April 2026 Deployment
The updates described in these release notes and the affected/linked documentation will not be available in the Punchh platform until the target deployment date.
Ava AI - Powered by PAR Intelligence
Ava Widget with Q&A Capabilities Is Now Live
We’re excited to introduce Ava, PAR’s restaurant AI, now available directly within the Punchh application. With this new widget, you can ask Ava questions about the Punchh platform and get instant answers. Ava is currently available to a limited group of customers. (MAI-2973, MAI-2962)

Action Required: Please contact your Punchh representative if you’re interested in enabling this feature for your organization.
Campaigns
Referral Campaign Enhancement for Fraud Prevention
Brands can now take control of their referral program gifting by setting a cap on how many rewards a member can earn through a referral campaign within a defined time window. This new configuration keeps referral programs fair, budget-conscious, and protected from repeat exploitation without disrupting the experience for legitimate participants. (CAM-7210, PDOC-3867)
Action Required: This feature does not impact any already configured or live referral campaigns. If you would like to add this feature to an existing referral campaign, you will need to edit the campaign manually and configure the proper fields.
See the following article(s) for more details:
- Referral Campaign (Support Portal)
Fix for Split Test Variant Distribution
We resolved an issue where split test campaigns did not consistently send variants according to the configured distribution (for example, 35/35/30). After this fix, deliveries accurately follow the percentages set during campaign setup. (EPS-11370, SQ-2004)
Offers
Solution for Expired Redeemables and Dynamic Rewards (Conditional Gifting)
We’ve continued to improve how Dynamic Rewards work with redeemables, building on similar updates we’ve made previously. As part of this ongoing effort, we’ve addressed an issue with conditional gifting where expired redeemables were being automatically removed from Dynamic Rewards. This behavior could prevent rewards from being gifted properly. With this update, expired redeemables will no longer be removed automatically. Instead, the UI will display a clear error message: “The attached redeemable has expired and can no longer be gifted to members. Please update it accordingly.” This continued improvement provides better visibility and more control for marketers managing Dynamic Rewards. (OMM-1820, OMM-1773)
Developers Corner
Multiple Enhancements in Loyalty Pay APIs
New Response Parameter in Single Scan Token API
The Generate Single Scan Token API (POST /api2/mobile/single_scan_tokens) response now includes a new parameter, location_id. This parameter is returned only when short_code is set to true and a valid location_id is provided in the request and a short_code is returned in the response. (PDOC-3811, LPE-1926)
Response Parameter Name Updated in Single Scan Token API
The response parameter expires_in has been renamed to expiring_at in the Generate Single Scan Token API (POST /api2/mobile/single_scan_tokens) when used for short code generation. This change improves clarity by indicating that the value contains an expiration timestamp. (PDOC-3811, LPE-1926)
New Response Parameter in Loyalty Short Code and Single Scan Token APIs
We have added a new boolean response parameter, new_short_code_generated, to the Drive-Thru API (POST /api2/mobile/drivethru_code) and the Single Scan Token API (POST /api2/mobile/single_scan_tokens) for the loyalty short code flow. A value of "true" indicates a new short code is generated and returned, while "false" indicates that a previously active short code is returned. (PDOC-3811, LPE-1885)
Updated Title for Mobile Single Scan Token API
The title of the Single Scan Token API (POST /api2/mobile/single_scan_tokens) article in the Developer Portal has been updated from “Generate a Single Scan Code” to “Generate Single Scan Code or Short Code”. This update reflects the API’s support for generating both single-scan codes and short codes. (PDOC-3811, LPE-1774, LPE-1926)
Updated Title for Mobile Loyalty Short Code API
The title of the Drive-Thru Code API (POST /api2/mobile/drivethru_code) article in the Developer Portal has been updated from “Generate a Drive-Thru Short Code” to “Generate Loyalty Short Code”.
See the following article(s) for more details:
- Generate Single Scan Code or Short Code (Developer Portal)
- Generate Loyalty Short Code (Developer Portal)
Peer-to-Peer Transfer Control Parameters in Program Meta API
We have added three new boolean response parameters, enable_points_transfer, enable_currency_transfer, and enable_rewards_transfer, to the Program Meta API (GET /api2/mobile/meta.json) to control peer-to-peer (P2P) transfers in the mobile app. These boolean parameters, based on the business program configuration, control whether users can transfer points, currency, or rewards to another user. A value of "true" enables the feature, while "false" disables it. Contact your Punchh representative to update this Punchh platform configuration. (PDOC-3812, LPE-1927)
See the following article(s) for more details:
- Mobile Program Meta (Developer Portal)
- Transfer Loyalty Points (Developer Portal)
- Transfer Loyalty Currency (Developer Portal)
- Transfer Loyalty Reward (Developer Portal)
Support for BIGINT (int64) in Redemption 1.0 and 2.0 APIs and Webhooks Event Payloads (Coming June 30)
Coming June 30, 2026, the data type of the reward_id, redemption_id, and redemption_code_id parameters will change from INT to BIGINT (int64) across POS, Online Ordering Redemptions 1.0 and 2.0 APIs, and Mobile Redemptions 1.0 APIs, as well as in some Webhooks Manager event payloads. This migration increases the supported range of ID values, helping prevent issues as ID values grow over time. Businesses now should ensure support for BIGINT (int64) values for these identifiers. The Developer Portal API documentation has been updated to reflect the supported data types for these parameters across the POS, Online Ordering, Mobile, and Webhooks Manager spaces. (PDOC-3645)
Note: No platform-side or API changes are required. If your integration uses smaller integer types (for example, Integer) for these parameters, you may need to update it to support larger values (BigInt / int64). See the following article(s) for more details:
- POS Possible Redemptions (Redemptions 1.0) (Developer Portal)
- POS Create Redemption (Redemptions 1.0) (Developer Portal)
- POS Void Redemption (Redemptions 1.0) (Developer Portal)
- POS Void Multiple Redemptions (Redemptions 1.0) (Developer Portal)
- POS Discount Look-up (Redemptions 2.0) (Developer Portal)
- POS Batch Redemption Process (Redemptions 2.0) (Developer Portal)
- Online Ordering Create Online Redemption (Redemptions 1.0) (Developer Portal)
- Online Ordering Fetch Redemption Code (Redemptions 1.0) (Developer Portal)
- Online Ordering Void Processed Redemption (Redemptions 1.0) (Developer Portal)
- Online Ordering Applicable Offers (Redemptions 1.0) (Developer Portal)
- Online Ordering Batch Redemption Process (Redemptions 2.0) (Developer Portal)
- Mobile Create Redemption Using Banked Currency (Redemptions 1.0) (Developer Portal)
- Mobile Create Redemption Using Visits (Redemptions 1.0) (Developer Portal)
- Mobile Create Redemption Using Redeemable (Redemptions 1.0) (Developer Portal)
- Mobile Create Redemption Using Reward ID (Redemptions 1.0) (Developer Portal)
- Mobile Cancel Redemption (Redemptions 1.0) (Developer Portal)
- Generate a Redemption Code for Subscription Redemption (Developer Portal)
- Webhooks Manager Event - Check-in - Gift and Loyalty (Developer Portal)
- Webhooks Manager Event - Redemptions (Developer Portal)
- Webhooks Manager Event - Rewards (Developer Portal)
Support for Double Data Type in User Balance and Check-in APIs (Coming June 30)
Coming June 30, 2026, the data type of the total_credits, loyalty_points, gift_points, and total_lifetime_points parameters will change from "Float" to "Double" to support a large range of values.
Note: No platform-side or API changes are required unless your integration limits the size of these numeric values (for example, uses Float). In such cases, you may need to update it to support larger values (Double). This change applies to the following APIs:
Mobile APIs
- Fetch User Balance (
GET/api2/mobile/users/balance) - Account Balance (
GET /api2/mobile/checkins/account_balance)
Online Ordering APIs
- Fetch User Balance (
GET /api/auth/users/balance) - Fetch Account Balance of User (
GET /api/auth/checkins/balance)
POS API
- Create Check-in (
POST /api/pos/checkins).
See the following article(s) for more details:
- Mobile Fetch User Balance (Developer Portal)
- Online Ordering Fetch User Balance (Developer Portal)
- Online Ordering Fetch Account Balance of User (Developer Portal)
- Mobile Account Balance (Developer Portal)
- POS Create Check-in (Developer Portal)