Callback fields at redemption, a redesigned Order History, and external member matching
Widget SDK 1.5.0 adds callback fields that pull redemption options from your own systems, the Order History is redesigned, and members match on your own ID.
01 ·Callback fields at redemption, powered by your own systems
You can now add a callback field to any redemption method in your store settings. When a trader opens the redemption form inside your embedded widget, the field does not show a fixed list of options. It asks your own systems for the options live, based on the context of that redemption, and shows whatever your systems return. The trader's choice goes through with the rest of the redemption.
Your systems get enough context to build the right options for that trader:
- The product being redeemed, by name
- The redemption fields configured for that method
The field handles its own loading, success, and error states in the widget. It ships as part of widget SDK version 1.5.0, which adds the callback capability along with developer documentation and setup examples.
When the detail you need varies by trader, such as an account number or a sub-account, the field can ask your systems for that trader's real options at the moment they redeem. The trader picks from a list that fits them, and your team gets the exact value it needs to fulfil the reward right then, so there is no chasing the trader for it afterwards.
02 ·Redesigned Order History in the client portal
We redesigned the Purchase History tab in the client-facing store. The order list is cleaner, with each row showing the product image, status, purchase date, order number, coin price, and a link to the full details. Opening an order shows a details view with a status timeline that tracks it through New Purchase, In Progress, and Completed. The timeline updates as your fulfilment team moves the order along.
Traders can also filter and search their order history:
- Category tabs (All, New Purchase, In Progress, Completed), each showing a live count
- Status sub-filters within each category, shown as pills that narrow to a specific status
- A search bar that matches across product name, order number, and status
A trader who can watch a redemption move from New Purchase to Completed sees the reward arriving, and that payoff is what makes earning the next batch of coins feel worth it. When they can find a past order and check a current one on their own, they stay in the earn-and-spend loop without stopping to ask your team where their reward is.
03 ·Designate your community's own member identifier
You can now designate one of your custom member fields as a community-scoped external identifier (your own customer or account ID) and use it as the matching key when you push data updates or run bulk imports. Once you set a field as the identifier, it appears pinned at the top of your custom fields list and is locked from editing. New members added to the community must supply it, and the platform enforces that it is unique within your community. Bulk data updates and imports can then match on that field rather than on email.
If your records key clients by an internal account number or a CRM reference, you can push updates and run imports matched on that field and skip normalising everything back to email first. The platform holds that field unique inside your community, so the matching key stays the one your systems already use and fewer records land on the wrong member.
04 ·Faster loading for Data Workflows history and event lists
The history list in Data Workflows and the event-ingest list both load faster. Each row used to load with all of its detail up front, which made the initial load slow for communities with a long history. The lists now load summary rows only, and the full detail for any record loads when you open it. Communities with active data integrations will notice the difference most.
Admins can now override the store's client-facing translations through the translation overwrite setting, so the wording traders see in the store matches your own terminology.
3 Jun