Make Loyalty Automation: Build Wallet Card Scenarios with Branching and Batches
Make loyalty automation builds scenarios that read your data, decide what a customer has earned and call the MSTRMND API on the Business plan. It suits branching rules and batches better than a single-trigger tool. This page covers how, and where it stops.
Via API and webhooks, Business plan
Build a Make scenario
- Draw the rule as a flow
- Choose the trigger or schedule
- Call the card API
- Add an error route
Test with one real card before launch.
What does Make loyalty automation do?
It lets you draw a loyalty rule as a flow. A Make scenario starts with a trigger or a schedule, passes data through steps, and can branch with a router into different paths. For MSTRMND, the steps include calls to the API and webhooks, which the Business plan provides.
The visual layout is the main reason owners and operations people choose it. A rule such as “double stamps on Tuesdays, but not for staff, and refunds always reverse” is easier to read as a flow than as a list of separate automations. Someone who was not there when it was built can still see what it does. New to wallet cards? Start with our guide to digital loyalty cards.
How a scenario talks to the card
A scenario reaches the card by calling the MSTRMND API through an HTTP step or a webhook. It can use the same actions any integration can:
- Find or create a customer and issue a card.
- Add or subtract a stamp, point, visit, purchase or transaction amount.
- Set a card expiry date or membership tier for subscription and membership cards.
- Send a push notification or an SMS to a customer.
Make’s own tools add what the API does not: filters, iterators for working through lists, aggregators for totals, and error routes for when something fails.
Four Make scenarios and the card actions they use
Each scenario pairs a flow with one or more calls to the MSTRMND API.
| Scenario | Make feature | Card action | Best for |
|---|---|---|---|
| Tiered rewards | Router with conditions | Add stamp or add point by branch | Different rewards for different customers |
| Nightly batch | Schedule and iterator | Add purchase for each sale | Daily sales files |
| Membership renewal | Trigger on payment | Set membership tier and expiry | Subscription and membership cards |
| Error alert | Error route | None: sends you a message | Catching failed calls |
Rules that suit a Make scenario
Different rewards for different customers
A router splits the flow by a condition. New customers get a welcome stamp, regulars earn on every visit, and a customer above a spend threshold gets a different reward. All three branches live in one scenario, so you change the rule in one place.
A nightly batch
A scenario runs on a schedule, reads yesterday’s sales from a spreadsheet or a system without live triggers, and adds each to the right card in one pass. That is the right tool for businesses whose sales data arrives as a daily file.
A membership that renews
For a subscription or membership card, a scenario can read a payment, then set the card’s membership tier and renewal date through the API. The card then reflects who is paid up, without manual updates.
Errors that tell you
When a call fails, an error route can send you a message or log the record. A loyalty system that fails silently is worse than none, because customers lose rewards without anyone noticing.
Card types you can drive from a scenario
Business includes all eight card types, so a scenario can serve several programmes.
Source: MSTRMND plan limits, checked 11 October 2026.
What you need before you start
- The Business plan, which includes API and webhooks.
- A Make account on a plan with enough operations for your volume. Check its current plans.
- The API credentials from your MSTRMND account.
- A matching key for customers: email or phone.
- A written reward rule, drawn as a flow before you build it.
Where Make stops
Make takes longer to learn than a single-trigger tool, and a large scenario can become hard to read if it grows without care. It is also a separate subscription and counts usage in operations, so a rule that touches many records can use many. For a very simple rule, a lighter tool is faster to set up. For something with real branching, a scenario is easier to maintain than a script.
Keeping a scenario readable
Make loyalty automation rewards care in the first week. A scenario that one person understands today is a scenario nobody can change in six months, unless it was built to be read.
- Name every module in plain words, such as “Find customer by phone”, not the default label.
- One scenario per rule. A single scenario that does everything is difficult to test and difficult to hand over.
- Leave a note on each router. Say in a sentence what each branch is for.
- Add an error route to every call to the card API, so a failure sends you a message.
- Keep a short change log with the date and what changed, so a reward that suddenly behaves differently can be traced.
- Test with a real card after every change, including the refund path.
None of this is difficult. It is simply easier to do on the first day than to repair on the hundredth.
Frequently asked questions
Is Make better than Zapier for loyalty?
It depends on the rule. Make suits branching, batches and rules you want to read as a flow. Zapier suits quick, single-trigger automations. Both reach the card through the API and webhooks on the Business plan, so you can start with one and move to the other if the rule grows.
Can a scenario run on a schedule?
Yes. A scenario can run on a schedule, read data from a spreadsheet or another system, and add purchases, stamps or visits to many cards in one pass. That makes it a good fit for businesses whose sales data arrives as a daily file rather than as live events.
What does it cost?
MSTRMND’s side is the Business plan, £115 a month billed annually, which includes API and webhooks. Make is a separate subscription and counts usage in operations, so check its current plans against the volume you expect. A rule that touches many records uses more operations than a simple one.
Do I need a developer?
Not for most rules. A scenario is built visually, and the API credentials come from your MSTRMND account. A developer helps if you need advanced matching, large volumes or custom error handling. If you want to start before any build, the Scanner App works on every plan.
Key takeaways
- Make loyalty automation builds scenarios that call the MSTRMND API on the Business plan.
- Routers handle different rewards for different customers in one flow.
- Schedules and iterators suit batches, such as a nightly sales file.
- Add an error route so a failed call does not silently cost a customer a reward.
- Make is a separate subscription that counts operations. Check its plans.