How It Works
One Catalogue,
Three Integration Paths
Clementine sits between two groups who can't reach each other efficiently on their own. Global consumer apps have users across North Africa but no way to charge them. Telecoms, retailers, OEMs and app stores have paying customers but no efficient way to source dozens of global apps one deal at a time. Clementine holds the publisher agreements, the local billing integrations and the Arabic and French localisation in one place, then makes that catalogue available to distributors through whichever of three technical paths fits their team.
The model in three steps
Clementine does not build the apps in its catalogue, and it does not build the storefronts its distributor partners already run. It solves the part in the middle, which is the part neither side can solve alone.
- ▸A publisher signs one agreement. One relationship covers all six markets instead of six separate negotiations. The publisher does no technical work: there is no SDK to embed and no API to call on their side.
- ▸Clementine does the local work. Carrier billing and mobile-money rails, Arabic and French localisation support, and local marketing, assembled once per market and reused across the whole catalogue.
- ▸Distributors offer the catalogue to their customers. Through their own app, their own storefront, or a ready-to-brand app. Those are the three paths below.
Why publishers integrate nothing
Most people get this backwards, so it is worth stating plainly: the SDK, the API and the white-label app are for distributors. A publisher joining the catalogue does not embed anything in their app, does not call an API, and does not ship a release to support Clementine.
That is deliberate. A global app's engineering roadmap is the scarcest resource in any expansion conversation, and requiring six carrier integrations to earn a market of uncertain size is why most global apps have no North African presence today. Remove the engineering ask and you remove the main reason the answer is usually "not this year."
Path 1: Mobile SDK
A drop-in SDK for a distributor that already has a consumer app with an installed base: a telecom's self-care app, a retailer's loyalty app, a bank's mobile app. The SDK adds Clementine's catalogue, checkout and entitlement handling inside the app the customer already has on their phone.
Best for distributors who have an app and an audience, and want to add a revenue line without building a storefront from scratch.
- ▸What's included: catalogue browsing and search, checkout against carrier billing and mobile-money rails, subscription and entitlement state, Arabic and French UI layers with full RTL.
- ▸What the distributor builds: placement and navigation inside their existing app, plus whatever merchandising they want around it.
- ▸Effort: the lightest engineering path that still gives you a real in-app surface. Scoped per partner. The variable is usually the host app's release cycle rather than the integration itself.
Path 2: REST API
A headless integration for distributors who want full control of the experience. Clementine's catalogue, billing and localisation are exposed as backend services. The storefront, the merchandising and the checkout UI are entirely the distributor's own.
Best for telecoms building a "content club" product, OEMs doing device-level bundling, and technically sophisticated partners with an existing design system and platform team.
- ▸What's included: catalogue and metadata endpoints, entitlement and subscription management, billing initiation and callbacks, localisation assets.
- ▸What the distributor builds: the entire front end, plus their own analytics and merchandising logic.
- ▸Effort: the heaviest path, and the one with the most control. Suited to partners who already run a platform team.
Path 3: White-label app
A complete, ready-to-brand iOS and Android app, pre-loaded with the catalogue, billing and localisation already wired in. The distributor applies its own name, logo and colours, then launches.
Best for distributors who want to move quickly with no engineering lift of their own, including partners who have a customer base and a billing relationship but no existing consumer app to build on.
- ▸What's included: the full app on both platforms, with catalogue, checkout, entitlements, and Arabic, French and English UI including RTL.
- ▸What the distributor provides: brand assets, store accounts, and the commercial relationship with its customers.
- ▸Effort: the fastest path to launch, and the least flexible on experience design.
Choosing an integration path
| | Mobile SDK | REST API | White-label app |
|---|---|---|---|
| Who it's for | Distributors with an existing consumer app | Distributors building their own storefront | Distributors with no app, or who want speed |
| Engineering lift | Moderate | High | Minimal |
| Control over experience | Partial, inside your app | Full | Branding only |
| Front end built by | Clementine (embedded) | The distributor | Clementine |
| Carrier billing & mobile money | Included | Included | Included |
| Arabic / French / RTL | Included | Assets provided | Included |
| Fastest to launch | Medium | Slowest | Fastest |
All three paths are distributor-side and draw on the same catalogue, the same billing rails and the same localisation work. Publishers integrate none of them.
Common questions
Do app publishers need to integrate an SDK?+
No. The SDK, REST API and white-label app are all distributor-side. A publisher joining the catalogue signs one commercial agreement and does no technical work: no SDK, no API calls, no app release.
Which markets does one agreement cover?+
All six: Morocco, Algeria, Tunisia, Libya, Mauritania and Egypt. The point of the model is that a publisher negotiates once rather than six times, and a distributor sources a catalogue once rather than app by app.
Can a distributor start on one path and move to another?+
The paths share one catalogue and one set of billing and localisation services, so they are different front ends onto the same back end. A distributor that launches on the white-label app to move quickly and later builds its own storefront on the API is following a normal progression, not migrating to a different product.
What kinds of apps is the catalogue built to carry?+
Health and wellness, education and language learning, entertainment, dating and social, mobility and delivery, productivity and consumer AI, travel, kids and family safety, and mobile gaming. Fintech, neobank and payment apps are explicitly out of scope, as is physical-goods e-commerce requiring customs-cleared shipping. These are the categories the platform is built for, not a list of signed titles.
Which side of the market are you on?
The two journeys are different, so the conversations are too.
Related reading
Sources
Figures on this page are drawn from the public sources below. Companies and deals referenced are cited as third-party industry precedent — none is a Clementine client, partner or completed deal.