Skip to main content

API mid July 2026 improvements (1.6.8)

Sam Critchley
Sam Critchley
Co-Founder

Additional API features, improvements and fixes that shipped to production in mid July 2026, on top of the earlier early July 2026 release.

  • Added a require_unique_phone_number chain option (set via alter-chain, returned by get-chain). When enabled, add-user and alter-user reject any request that would give two active accounts in the same app the same phone number, returning the new phone_number_already_exists error (code 555). When disabled (the default), duplicate phone numbers are still allowed and are only flagged via the phone_number_duplicate field. Enforcement applies to new writes only; accounts that already share a phone number are left unchanged when the option is enabled.
  • Added two value_calculation_rule options for wallet_contribution reward methods on composable campaigns, configured through alter-reward-method: fixed_value_per_basket awards the configured value once per qualifying basket, and fixed_value_per_spend awards the value for each spend_step of basket spend (using the new spend_step reward-method field). Unlike the existing per-item fixed_value rule, both are independent of item quantity.
  • Added the get-campaign-barcode-conflicts endpoint. Given a chain, a list of barcodes and a reference date window, it returns each barcode that is shared with another campaign whose active date window overlaps the reference window, along with those campaigns' details. This makes it possible to detect barcode and scheduling clashes between campaigns in a single request.
  • Changed the chain basket_campaign_require_format_assignment option so that a Business (store) assignment now also satisfies the requirement. When the option is enabled, an active BasketCampaign is accepted if it has either a Business Format assignment or a Business (store) assignment, aligning the API with the Console campaign activation checklist.
  • Changed date-time fields in Resources API responses to RFC 3339 format (a profile of ISO 8601), normalised to UTC (for example 2026-07-07T15:30:23+00:00), for API version 1.6.8 and above. Earlier API versions continue to receive the previous Y-m-d H:i:s format for backwards compatibility.
  • Removed the shopper object from the transaction/receipt response. Member identity is now carried solely by the user field, which already contains the same name, contact, membership and address details, so the duplicate shopper block is no longer returned.