API-only loyalty: the programme is still yours to build

An API-only loyalty platform hands you a transaction and promotions engine you reach over REST calls. It does not hand you the app, the wallet screen, the receipt logic, or the enrolment flow. Every pixel a member touches, you build. That is the correct architecture. It also means the loyalty programme is a software project you own, staffed by your team or a system integrator, and billed by the day.

What does API-only actually leave on your plate?

Eagle Eye AIR describes itself as an API-based, composable platform, and on its own AIR platform page the pitch is integration: connect the engine to any back-end or partner system. That is accurate, and it is the point. The engine holds the balances, evaluates promotion rules, issues and redeems offers, and stores the member wallet. What it does not do is render anything a human sees.

Everything on the surface is yours to design, build, test, translate, and maintain: the mobile app, the web account, the till and e-commerce integration, the enrolment and age-gating flow, the email and push templates, the distributor or trade portal. A packaged loyalty product ships some of those screens in the box. A headless engine ships none of them. If you have ever watched a “retail suite” turn out to need a year of integration before go-live, this is the same shape in a different aisle — the same gap we picked apart in the plug-and-play retail suite that isn’t.

And it is not a one-off cost. Every screen you build becomes a screen you own forever: it has to track the engine’s API changes, survive iOS and Android release cycles, get re-tested when a promotion type changes, and get re-translated when you open a market. Headless shifts the initial build to you; it also shifts the maintenance tail, which is the part nobody demos.

Why is the professional-services line so large?

You do not have to take a sceptic’s word for how much building is involved — it shows up in the vendor’s own accounts. In its half-year results, Eagle Eye reported professional services of £4.4m, around 18% of revenue, with a further £5.4m of professional-services revenue deferred. That is not a rounding error bolted onto a self-serve product. That is the build, and there is enough of it in flight to defer millions of it into future periods.

The direction of travel is just as telling. The same results set out a pivot to system-integrator-led delivery, targeting 50% of new ARR through partners by FY26. Read that plainly: the platform is deliberately built to be implemented by integrators, and the implementation is substantial enough to be a channel strategy. None of this is a knock on the software. It is a statement about where the work lives.

An SI-led model is not automatically worse for the buyer — a good integrator brings reusable accelerators and market experience the vendor cannot. But it changes the negotiation. You are now buying a licence from one party and a build from another, with the incentive to under-scope the build sitting on the sales side of both. The number to chase is not the annual platform fee; it is the fully loaded cost of first go-live plus two years of change.

Who owns the build, and at what day rate?

API-first is the right call. The honest question is not whether the architecture is sound; it is who holds the pen and who holds the invoice. There are only three answers — the vendor’s own professional-services team, a third-party integrator, or your own engineers — and each comes with a day rate and a maintenance tail. The engine is close to a commodity. The cost and the differentiation live in the surface you wrap around it.

It helps to be concrete about which side of the line each piece falls on:

Every row on the right is a screen, a test suite, and a backlog owner. Before signing, you want that column costed and assigned to a name. The trouble is that these engagements are hard to price-check from the outside, because there is almost no independent review of who delivers beverage loyalty builds well — the same gap we complained about in the software your industry runs on has no reviews.

Where does this bite a beverage rollout specifically?

A brewer does not run one loyalty programme. It runs a portfolio: a consumer app in one market, a trade or wholesaler scheme in another, returnable-deposit incentives in a third, on-premise and off-premise mechanics that behave nothing alike, each under its own alcohol-marketing rules and age-gating regime. The engine scales to all of it happily. The front end does not come free per market — every territory wants its own screens, its own language, its own compliance copy, and someone has to build them and keep them alive.

There is a second-order cost that is easy to miss at signing. A loyalty engine that only talks to itself is a personalisation tool that cannot see the order, the delivery, or the returnable. If the member ledger does not sit on the same event bus as order capture, stock and returnables, you have bought a clever silo. And the failure mode when a vendor owns that layer and then changes course is exactly the one we described in when the vendor sunsets your marketing stack. We treat loyalty as one more service on the shared bus for that reason — the thinking is in how we lay out the event-bus architecture.

So what is the actual fix?

The direction is simple to state and easy to skip: treat the loyalty engine as one service behind a UX layer and an event bus you own, and budget the customer-facing build as a capitalised software project with a named owner and a day rate you agreed before signature — not a licence line you discover in year two. API-first does not remove the build. It just decides who is holding it.

The API-only pattern is not staying in loyalty. Commerce, CDP and offer management are all going headless across the route-to-market stack, and each headless vendor arrives with a build attached. The brewers who come out ahead over the next few cycles will be the ones who stop reading “platform” as “finished product” and start pricing every engine with its integration bill on the same line of the business case.