Skip to main content

API mid August 2026 improvements (1.6.8)

Sam Critchley
Co-Founder

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

  • Added survey campaigns, a composable campaign with context: "survey". The survey questions are configured on the campaign through survey_definition in add-campaign and alter-campaign, client applications fetch the definition and the shopper's completion state with GET /survey, and answers are submitted with POST /submit-survey. Completion is idempotent per shopper and campaign, issues the campaign's direct reward methods, and enforces the campaign's segment restriction on both retrieval and submission. Completed responses can be retrieved with GET /internal/get-survey-responses.
  • Added email address verification, configured per chain with the email_verification_method option (off, otp or deeplink) through alter-chain and returned by get-chain. See verifying user contact details for the full flows.
  • Added an email one-time passcode flow: otp-request and otp-verify accept an email parameter to send a six-digit passcode to a user's email address and verify it, mirroring the existing phone number flow with the same rate and attempt limits.
  • Added an email verification link flow with the new email-verify-request and email-verify endpoints, which email a signed, single-use verification link that is valid for three days.
  • Added an email_status field to the user, returned by get-user, showing whether the email address has been verified (1) or not (0). Changing a user's email address through add-user or alter-user resets email_status to unverified.
  • Added privileged authentication for the Resources API, so a service client can use a bearer access token in the X-Spaaza-Access-Token header instead of an administrator session. See authentication for the resources and operations available.
  • Added end-user (shopper) authentication for the Resources API, allowing a customer to retrieve their own data with the session credentials returned by login plus the X-Spaaza-MyPrice-App-Hostname header. GET requests are supported on the Business, Voucher and ContentPage resources, results are limited to the customer's own data and their app's chain, and properties that are only relevant to administration are omitted from the response.
  • Changed the default voucher filtering for end-user Resources API requests: GET /resources/vouchers returns only vouchers with status generated or claimed unless redeemed vouchers are requested explicitly, for example GET /resources/vouchers?status=redeemed.
  • Improved authentication handling so that a customer session is validated against the chain of the app making the request, and can no longer be used with an app belonging to a different chain.
  • Fixed purchase progress distribution so that a campaign contributing progress into a wallet or stamp card honours its own earn_on_promotional_items setting, and no longer awards progress for promotional items when that setting is false.
  • Fixed the counting of issued honour_voucher rewards against a reward method's usage_limit, so a composable campaign can no longer issue more rewards than the configured stock allows.
  • Fixed the status filter on Resources API voucher requests, so GET /resources/vouchers?status=claimed now returns the matching vouchers.
  • Fixed Shopify registration and customer synchronisation: registering with an email address that already exists in Shopify now returns the intended duplicate email error rather than a generic server error, customer lookups require an exact email address match so a similar address is never adopted, and synchronising existing Shopify customers into Spaaza no longer fails for customers without an existing programme opt-in.