SDK vs. API vs. White-Label: Which Integration Path Fits Your Platform
SDK vs. API vs. White-Label: Which Integration Path Fits Your Platform
Once a distributor — a telecom operator, retailer, OEM, or bank — decides to offer North African customers a catalogue of global apps, the conversation shifts fast from “should we” to “how.” That’s a technical and organizational question as much as a commercial one. Brokered distribution models like this already work in the region — Carry1st and Tamatem, for instance, already broker global game publishers into MENA markets through local payments and marketing — but the specific integration path a distributor should choose depends entirely on what they’ve already built, how much engineering time they can spend, and how much control they want over the end-user experience.
Clementine offers three integration paths for exactly this reason: a Mobile SDK, a REST API, and a white-label app. All three are built for the distributor side of the relationship — none of them is something a publisher installs or integrates. A publisher’s app just gets listed in Clementine’s catalogue and gets paid through carrier billing and mobile-money rails, wherever a distributor is running one of these three paths; the publisher doesn’t build or choose anything on this list. What follows is a decision framework for the distributor making that choice.
The Three Paths at a Glance
| Path | Best fit for | What you control | What’s handled for you |
|---|---|---|---|
| Mobile SDK | Distributors with an existing app who want a fast way to list and monetize the catalogue inside it | Your app, your brand, your product experience | Catalogue listing, carrier billing, mobile-money payment, Arabic/French UI layers |
| REST API | Technically sophisticated distributors building something custom | Your entire storefront, checkout, and UX | Catalogue, billing, and localization as backend services |
| White-Label App | Distributors without an existing app who want to move fast | Your brand name and logo on a finished product | The app itself, plus catalogue, billing, and localization, pre-wired |
Start Here: Do You Already Have an App?
The fastest way to narrow this down is to ask a more basic question first: does your organization already have an app your customers open regularly, or do you have a customer base but no relevant app at all?
If you already have an app — a telecom’s self-care app, a bank’s mobile banking app, a retailer’s loyalty app, anything with its own regular install base — your real choice is between the SDK and the API. You’re not starting from zero; the question is how much of the catalogue-listing and payment complexity you want handled for you versus how much custom control you want to build around it.
If you have a customer base but no relevant app — you want to offer a catalogue but have nothing to add it to — your real choice is between the white-label app and the API. You’re not modifying an existing product; the question is whether you want a finished, ready-to-brand app you can launch quickly, or whether you’d rather build a bespoke catalogue app from scratch using Clementine’s infrastructure as the backend.
In both cases, the REST API is the “advanced” option: it demands the most engineering investment of the three, in exchange for the most control over the final experience.
If You Have an Existing App: Mobile SDK vs. REST API
Team size and technical sophistication. A distributor without dedicated payments or catalogue-merchandising engineering is the clearest signal to choose the SDK — it’s built specifically so you never have to solve carrier billing, mobile-money integration, or Arabic/French UI layers in-house. A distributor with dedicated backend or platform engineers, and a reason to make the app catalogue feel fully native to a broader in-house product rather than a drop-in component, is a better fit for the API.
Timeline. If the priority is getting a catalogue live without opening a multi-month engineering project, the SDK is the shorter path — it drops into your existing app rather than requiring a storefront to be built around it. The API asks for a longer runway in exchange for a more bespoke result.
Control. Distributors comfortable with a proven, ready-made catalogue and billing flow should default to the SDK. Distributors that need pixel-level control over checkout, want to merchandise the catalogue in a specific way, or need it woven into a highly custom user flow should default to the API.
As a rule of thumb: an existing app that mainly wants a global-app catalogue and North Africa’s payment infrastructure solved, without changing how the rest of the product looks or feels, fits the SDK. An existing app that wants to build something more tailored on top of the catalogue and billing rails — and has the engineering time to do it — fits the API.
If You Don’t Have an App Yet: White-Label App vs. REST API
Team size and technical sophistication. A distributor without in-house mobile engineering — or one whose engineering capacity is committed elsewhere, to network operations, retail systems, or core banking — is the natural fit for the white-label app: there’s no engineering lift required beyond branding and launch approval. A distributor willing to invest in a bespoke mobile product from the ground up is better served by the API as backend infrastructure for an app it designs and builds itself.
Timeline. If the goal is to have a branded offering in customers’ hands as soon as possible, the white-label app is the faster route — it arrives built. If the goal is a fully custom mobile product built from scratch, the API is the right investment.
Control. A distributor comfortable branding and launching a pre-built app should default to white-label. A distributor that wants to design its own end-to-end mobile product, and only needs the catalogue, billing, and localization as backend services, needs the API to make that possible.
A Simple Self-Check
Four questions tend to settle most of the ambiguity for a distributor:
- Do you already have an app your customers open regularly? If yes, you’re choosing between SDK and API. If no, you’re choosing between white-label and API.
- Do you have engineering capacity you’re willing to dedicate to a custom integration, or do you need this handled for you? Capacity to spare points toward the API. Need it handled points toward the SDK or white-label.
- Is speed to market or long-term product control the bigger priority right now? Speed points toward SDK or white-label. Control points toward the API.
- Will you need to deeply customize checkout, bundling, or merchandising beyond a drop-in or pre-built experience? If yes, that’s an API-shaped requirement. If no, the SDK or white-label path will get there faster.
The Paths Share the Same Foundation
Whichever path fits, it’s worth remembering the three options aren’t three different products — they’re three different levels of front-end ownership a distributor takes on, sitting on top of the same catalogue, carrier billing, mobile-money, and localization foundation. Choosing between them is a question of a distributor’s engineering resources and desired control, not a question of which publishers, categories, or markets they get access to. That’s a deliberate design choice: the integration path should be the easy decision, so the harder work of actually reaching North Africa’s consumers can start sooner. And whichever path a distributor picks, it doesn’t change anything on the publisher side — publishers get listed and paid across all of them the same way, with no integration work of their own.
