The open-source loyalty engine that isn't open anymore

Open Loyalty ships two very different things under one name. The open-source edition sits on GitHub without support, updates, or a UI layer — effectively frozen reference code. The product brewers actually buy is a closed enterprise API, metered on monthly active members and fenced by documented hard limits: a 30-second request timeout, pagination capped at page 500, and a 100MB import ceiling. 'Open source' here is a label, not a maintenance guarantee.

What does the open-source edition actually give you?

Not much you would run in production. The repository on GitHub is real, but reviewers describe it plainly. Per the rewardloyalty.co comparison, the open-source edition:

exists on GitHub but comes without support, updates, or a UI layer

Read that as three separate problems. No support means no one to call when a promotion misfires at month-end. No updates means the security and dependency baseline drifts the moment you clone it — the same slow-motion decay we described in the WMS mods that vanish with every upgrade, except here the base platform itself has stopped moving. No UI layer means your operators get an API and a wish. The commercial product — the one with a console, connectors and a roadmap — is a closed enterprise API, priced on monthly active members. You are not buying open source with an optional support contract; you are buying SaaS with an open-source-flavoured README.

Where do the documented limits actually bite?

The enterprise API publishes its ceilings, which is more honest than most vendors manage. As of February 2026, the official limits page documents the following:

The same page notes that the 40-requests-per-minute cap on authentication becomes hard-enforced on 15 September 2026, so any integration currently leaning on generous token issuance has a deadline. None of these numbers is unreasonable on its own. The problem is what a national beer loyalty programme looks like when you multiply them together.

Why do those numbers matter for a brewer's loyalty programme?

Start with pagination. A loyalty base for a top-three global brewer runs into millions of members. A cap at page 500 means any endpoint you paginate stops handing you rows after 500 pages, whatever your page size. If you assumed you could walk the full member list for a nightly export, you get a silent horizon instead of an error — the same failure shape as 2,000 buyer groups and your search silently breaks. You do not find out at design time; you find out when finance asks why the reconciliation is short.

Now the expression limit. Real promotions are not 'buy six, get points.' They are 'buy six of these SKUs, in these outlets, during this window, unless the outlet is in this returnable-deposit scheme, then apply a different multiplier.' Encode that in 500 characters and you are golfing your business rules rather than writing them. Teams route around it by chaining rules or pushing logic into middleware — which is exactly how promo logic ends up hitting an invisible wall, the pattern we unpicked in governor limits: when your promo logic hits an invisible wall.

The 30-second timeout and the 100MB import bound the batch world. Distributor sales files at national scale routinely exceed 100MB, so every load becomes a chunk-and-retry pipeline with its own error handling and its own reconciliation. Any enrichment or segmentation that touches the whole base has to finish inside 30 seconds or be redesigned into smaller asynchronous jobs. And the 40-requests-per-minute auth ceiling quietly caps how many independent services can hold their own credentials: order capture, the consumer app, the call centre and the returnables service all competing for the same minute of token issuance. Each of these is survivable in isolation. Stacked, they turn a 'configure it' project into an 'engineer around it' one.

Is the real risk the limits, or the label?

The limits are documented and, mostly, defensible. The real risk is the word on the tin. 'Open source' on a vendor page reads as 'we can self-host, fork, and outlast the vendor's roadmap.' Here it means a frozen reference implementation with no UI and no updates, sitting next to a metered SaaS you cannot fork. Procurement sees the licence and relaxes; engineering inherits a per-active-member meter and a set of ceilings that only surface under production load. The gap between those two readings is where budgets and timelines quietly go to die. A maintenance-reality check — who patches it, who ships the next version, what breaks at your member count — belongs in the evaluation, not the post-mortem.

The direction out is not to fork the frozen repo and hope. It is to decide whether loyalty is core enough to own outright. When earning rules, member state and returnables all sit on your own event bus, the meter disappears, the 500-character rule box becomes ordinary code your team can test, and pagination is just a query you control — the case we make for an owned route-to-market architecture rather than a rented one.

The next few procurement cycles will test how many 'open' loyalty stacks are open in any way that matters. As the September enforcement date approaches and active-member counts climb with every market you add, the question stops being whether the platform is on GitHub and becomes whether you can change a reward rule on a Friday without asking a vendor's rate limiter for permission.