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:

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:

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:

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:

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_creditsloyalty_pointsgift_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: