The White-Label Capability Framework
Understand what “white label” actually means, identify the maturity level you need, and compare software on the capabilities that matter.
When searching for white-label software, you will encounter terms such as white-label rebranding, white-label SaaS, reselling and embedded software. The problem is that these terms are not used consistently.
Some providers have a dedicated white-label offering with detailed documentation. Others mention “white label” in a SEO meta description or blog post without explaining what can actually be branded or configured. We have also found software listed as white label by third-party websites while the vendor itself describes a much narrower offering.
That makes it difficult to answer a basic question:
What can I actually make my own?
The White-Label Capability Framework provides a consistent way to answer that question.
It focuses on two capability domains for the baseline review: Brand and Flexibility. Together, they show what your customers see and how much you can adapt the software to your own offering.
The framework also recognises three further domains: Control, Trust, and Commercial & Operations which become important when carrying out deeper due diligence.
How the framework works
The framework uses three maturity levels:
| Level | Maturity | Definition | Typical buyer fit | Core question |
|---|---|---|---|---|
| Level 1 | Brandable White-Label | The buyer can apply its brand identity to the software through elements such as its logo, colours, domain, and selected customer-facing surfaces. Adaptation is generally limited to existing settings and available options, with limited ability to change how the software works or is tailored to different needs. | Branded Business | Can I make it look like my brand? |
| Level 2 | Enhanced White-Label | The buyer can establish a more consistent branded experience and meaningfully adapt how the software is configured, presented, and operated. This may include customising customer-facing experiences, managing multiple customers, configuring workflows, controlling feature access, or packaging the software as its own offering. | Branded Business, Agency, Reseller | Can I adapt and operate it as my own offering? |
| Level 3 | Deep White-Label | The buyer has extensive control over the branded experience and how the software is adapted, extended, or integrated. This may be achieved through advanced no-code/low-code tools, developer capabilities, or a combination, allowing the software to form a substantial part of the buyer’s own product or broader solution. | Agency, Reseller, SaaS Builder, Solution Integrator | Can I make this substantially my own? |
The levels are indicative rather than strict checklists; maturity is assessed based on the overall breadth and depth of branding and flexibility capabilities and the degree of control they provide to the buyer, rather than the number of features available.
Buyer Fit
The framework identifies five typical buyer types based on how they intend to use, adapt and commercialise white-label software.
Branded Business: A business that wants to use software under its own brand to strengthen its brand identity, improve customer experience, support its operations, or extend its existing offering without building software from scratch. The software may be used internally or provided to the business's own customers as part of its existing products or services.
Branded Businesses typically seek to leverage their existing brand recognition and customer relationships, deliver a consistent branded experience, differentiate their offering, improve customer retention, and create additional value for their customers. They generally prioritize straightforward branding, ease of implementation, operational fit, and control over the customer-facing experience.
Branded Businesses typically value:
- Custom branding and domain
- Branded customer-facing interfaces
- Ease of setup and administration
- Configuration to suit their business needs
- Control over the customer experience
- Integration with existing business processes
- User management and access controls
- Reliable functionality with minimal development overhead
Their core commercial question is:
Can I use this software under my own brand to strengthen my business, improve the experience I deliver, and create more value for my customers?
A Branded Business does not necessarily intend to sell the software itself as a standalone product or build a separate software business. Its primary objective is to use branded software to support, strengthen, or extend its existing business and customer offering.
- Agency: A business using a white-label platform to deliver services to multiple clients under its own brand. Agencies typically need multi-client or sub-account capabilities, easy client management and the ability to configure the offering for different clients.
The software may be an important component of what the agency sells, but it is not necessarily the primary product being sold. Agencies typically value:
- Multi-client or sub-account capabilities
- Centralized client management
- Client-level configuration
- Standardized service delivery
- White labeling
- Feature and access controls
- Packaging and bundling
- Easy provisioning and administration
Their core commercial question is: Can I use this software to deliver and manage a repeatable service for multiple clients?
An agency may also be a reseller if it charges customers specifically for access to the software. The distinction is that an agency's offering is typically broader than the software itself.
- Reseller: Within the iwhitelabel framework, the focus is on white-label resellers: businesses that sell access to another provider’s software as their own branded offering. They need the ability to package, price and sell the software as their own offering, with capabilities to manage multiple customers and, where required, operate separate customer environments.
White-label resellers typically value:
- Wholesale or reseller pricing
- Pricing and margin control
- Packaging and plans
- Feature visibility
- Customer provisioning and management
- Multiple customer environments
- Custom branding and provider branding removal
- Billing and commercial controls
- Sales and customer-management capabilities
Their core commercial question is: Can I package, price, and sell this software as my own branded offering?
A white-label reseller may provide additional services, but selling access to the software itself remains central to its commercial model. An agency and a white-label reseller may share many requirements, particularly branding, multi-customer management, packaging, and configuration. However, they differ primarily in what they commercialise: an agency sells services delivered using the software, while a white-label reseller sells access to the software as its own branded product.
Scope note: iwhitelabel focuses on white-label resale rather than conventional reselling or referral arrangements where the provider retains the primary customer-facing brand and commercial relationship.
- SaaS Builder: A business or product team using a platform as the foundation for its own software product. SaaS Builders typically need deeper customisation, integration and commercial capabilities, often supported by APIs or SDKs, to create an experience that is substantially their own. Rather than simply reselling the existing product, the buyer wants to create a differentiated customer experience and potentially build proprietary functionality around the underlying platform.
SaaS Builders typically require:
- APIs
- SDKs and developer tools
- Deep customization
- Integrations
- Programmatic control
- Custom workflows
- Data access
- Headless operation or API-driven functionality
- Greater control over the customer experience
- Advanced commercial and provisioning capabilities
Their core question is: Can I build my own software product on top of this platform?
- Solution Integrator: A technical operator integrating the platform as a technical component within a larger product, application or infrastructure environment. The platform may not be the product being sold directly. Instead, it provides functionality that the integrator combines with other systems, hardware, software or services.
Solution Integrators typically require:
- APIs
- SDKs
- Webhooks
- Integration capabilities
- Data access
- Automation
- Technical control
- Interoperability with other systems
- Programmatic provisioning and management
Their core question is: Can I integrate this functionality into a larger technical solution?
Buyer types are indicative associations rather than fixed rules. Buyer type reflects the buyer’s primary commercial objective, while white-label maturity reflects the degree of branding and flexibility the platform provides. A buyer may therefore require a higher or lower maturity level than is typical for its buyer type, depending on its specific needs.
Maturity can also be achieved through different routes. Some platforms offer extensive no-code or low-code configuration and customisation, while others provide greater control through developer capabilities such as white-label APIs and SDKs. Some combine both approaches.
The practical approach is to assess the platform’s overall capability profile, identify the maturity level its capabilities support, and determine how well that profile fits the buyer’s objectives and requirements.
What we verify
The baseline review is designed to be repeatable across a large number of software products.
A software website is added to the directory before it has necessarily been verified against the framework. Verification is a separate step.
Good signals include a dedicated white-label page, product documentation explaining the white-label offering, and knowledge-base articles showing how to enable or configure white-label features. A mention of “white label” in a blog post or SEO title alone is not considered sufficient evidence.
A listing receives a Verified designation when the capabilities can be confirmed through the software itself, normally by logging into the application and/or supported by provider documentation where relevant.
Capability Domain 1: ✦ Brand
Brand answers the most visible white-label question:
Can I make the software look and feel like my own?
Brand goes beyond uploading a logo. A genuinely branded experience can extend across the customer-facing application, login experience, emails, reports and other touchpoints.
The exact capabilities vary by platform, but the review looks for the following.
| Brand capability | What we look for |
|---|---|
| Logo / brand assets | Buyer can upload and apply its own logo and core brand assets (mark, wordmark, icon) in the live product, in place of the provider’s defaults. |
| UI brand configuration | Buyer can apply a brand kit across the interface — colours, fonts, and visual styling — so surfaces match the buyer’s look. Custom CSS can count, but a theme or brand-kit control is enough. Example: a chat widget or chat pop-up uses the buyer’s colours and logo, not the vendor’s. |
| Favicon | Buyer can replace the provider favicon so the browser tab (and app/PWA icon, if the product has one) shows the buyer’s icon. |
| Branded frontend | The customer-facing application — screens, navigation, labels, and customer portal — is shown as the buyer’s product, without the vendor’s name, logo, or default visual identity. |
| Branded login | The sign-in page, plus registration and password-reset screens, uses the buyer’s logo, colours, and copy rather than the provider’s. |
| Custom domain | The product opens on the buyer’s domain or subdomain (e.g. app.buyer.com) after DNS setup, with a valid SSL certificate on that hostname. Look for documented hostname mapping plus certificate setup, including automated DNS and SSL where the vendor offers it. |
| Branded emails | Transactional and system emails (invites, password resets, notifications, invoices) send as the buyer: buyer From name/address and branded templates. Setup is either custom SMTP or provider-managed sending from a verified buyer domain. |
| Branded reports / documents | Generated customer documents — reports, PDFs, exports, invoices — show the buyer’s logo, colours, and header/footer rather than the provider’s. |
| Backend dashboard branding | The admin / operator dashboard used by the buyer’s employees and sub-admins is branded as the buyer’s product, so internal users do not see the true vendor. |
| Per-client branding | Individual customer or tenant accounts can use their own brand kit (logo, colours, and where offered their own hostname), not only one agency-wide theme. |
| Provider branding removal | Vendor name, logo, “powered by”, and other provider-identifying marks can be turned off or removed from the customer experience. |
| Branded mobile app | A mobile app or PWA shows the buyer’s app name, icon, splash screen, and interface rather than the provider’s. |
| Branded app-store app | A store-listed Android and/or iOS app can go out under the buyer’s own Play Console / Apple Developer account, with the buyer’s app name, icon, and store listing. |
| Branded customer support surfaces | The customer-facing help centre, knowledge base, in-app help, or docs site can use the buyer’s brand rather than the provider’s support site. |
Brand maturity
| Level | Brand maturity | Definition | Typical buyer fit |
|---|---|---|---|
| Level 1 | Brandable White-Label | The buyer can apply its core brand identity to the software, typically through its logo, colours, and basic customer-facing branding. Branding may extend to selected areas such as customer-facing reports and documents, while broader product surfaces and the underlying experience remain substantially controlled by the provider. | Branded Business |
| Level 2 | Enhanced White-Label | The buyer can establish a more consistent branded experience across the main customer-facing touchpoints, with broader control over elements such as the frontend, login screens, custom domains, transactional emails, and provider branding removal. | Branded Business, Agency, Reseller |
| Level 3 | Deep White-Label | The buyer can exercise extensive control over the software's branding across relevant product surfaces and customer experiences. Depending on the platform, this may include separate client branding, backend dashboards, mobile apps, app-store listings, and customer support surfaces, enabling the software to operate as a more fully branded product or solution. | Agency, Reseller, SaaS Builder, Solution Integrator |
Capability Domain 2: ⚒ Flexibility
Flexibility answers a different question:
How far can I adapt the software to the way I want to operate?
Flexibility is broader than configuration. It covers how the platform can be adapted for customers, how functionality can be packaged and monetised, how it can support different markets, and how it can connect with other systems.
Flexibility can be achieved through No-Code / Low-Code capabilities or through Developer / Code capabilities. No-code and low-code provide flexibility through configuration, visual tools and pre-built functionality, while developer capabilities can provide a greater degree of technical control and customisation through a white-label API or white-label SDK. A platform may support either approach or both.
Flexibility Capabilities
No-Code / Low-Code Capabilities
No-code and low-code capabilities allow buyers to adapt the software through settings, visual tools and pre-built functionality. These capabilities can determine how extensively the software can be tailored for different customers and use cases without custom development.
Configuration & Workflow
| Capability | What we look for |
|---|---|
| Basic no-code configuration | Buyer can change standard product settings in the admin UI without writing code — toggles, labels, defaults, notifications, and turning modules on or off. |
| Visual builder | Buyer can design or substantially change customer-facing experiences with a visual or drag-and-drop builder (pages, flows, emails, widgets). Editing raw HTML or code alone does not count. |
| Custom fields / forms | Buyer can add or adapt data fields and forms (text, select, date, file, and similar) so records and intake match its own data model. |
| Workflow configuration | Buyer can build a multi-step process in this product (trigger → a run of actions the platform executes), such as notify → assign → update a record. |
| Conditional logic | That in-product workflow or form can branch: if a field, plan, role, or event matches a rule, the product takes a different path. A straight trigger → action run is not enough. |
| Custom pages / interfaces | Buyer can create or substantially change customer-facing pages or views (landing pages, portals, dashboards), not only rearrange widgets on a fixed layout. |
| Native integrations | Pre-built connectors in the product’s integration list connect to other services without custom development — for example CRM, calendar, payments, or email tools. A generic API is not this capability. |
| Webhooks | Buyer can register an HTTPS endpoint so the product sends event payloads when defined actions occur (signup, status change, payment). |
Customer & Account Management
Customer and account management determines how effectively a white-label platform can be structured around multiple customers. This is particularly relevant where the buyer needs to operate separate customer environments from one platform.
| Capability | What we look for |
|---|---|
| Multi-client / sub-accounts | Buyer can create and manage multiple customer accounts from a central account or dashboard, with a clear client/sub-account structure. |
| Per-client configuration | Settings, workflows, fields, modules, branding or other functionality can be configured differently for individual customer accounts rather than only at the parent-account level. |
| Feature visibility | Features or functionality can be shown, hidden or enabled by customer, account, package or plan, allowing the buyer to control what each customer can access via the admin UI). |
| Roles & permissions | Access can be controlled by role and, where supported, by customer account, including what internal staff, customer administrators and end users can view or modify. |
| Reseller management | The provider allows the buyer to provision and administer customer accounts as part of its own resale operation, including creating, activating, suspending, updating, and managing customer accounts from a centralized reseller or administrator interface. |
| Multi-tenant management | Customer environments and data are logically separated so that customers cannot access or inadvertently affect other customers' data or configuration. |
Packaging & Monetisation
Packaging and monetisation capabilities allow buyers to structure the software into different customer offerings and control how those offerings are priced, billed and paid for.
| Capability | What we look for |
|---|---|
| Subscription & pricing configuration | Buyer can create and manage customer plans, packages and prices within the product — such as monthly or annual subscriptions, usage-based pricing, per-seat pricing, one-time fees, or other supported pricing models. The vendor's own pricing page does not count. |
| Configurable billing | Buyer can configure how customers are billed — such as billing intervals, trial periods, proration, taxes, discounts, credits, or similar billing rules. |
| Payment gateway integration | Customer payments can be processed through a connected payment gateway used by the buyer (for example, Stripe or similar), with funds paid to the buyer's merchant account rather than the vendor's account. |
| Client billing / invoicing | Buyer can create and manage customer invoices or billing records in the product — such as generating invoices, sending invoices, tracking payment status, or managing billing records. The vendor's invoice to the buyer does not count. |
Localisation
Localisation determines how well a white-label offering can be adapted for customers operating in different languages, currencies and regions.
| Capability | What we look for |
|---|---|
| Language localisation | The product can run in more than one language for customers or accounts — language pack, locale switcher, or per-account language — not only a translated marketing site. |
| Currency | Prices, balances, or billing can use more than one currency, or the buyer can set the currency per customer or account. |
| Time zones | Customer or account time zones can be set so dates, schedules, and logs follow that zone. |
| Localised formats | Date, number, and measurement formats can follow the customer’s locale (e.g. DD/MM/YYYY vs MM/DD/YYYY, metric vs imperial). |
| Local payment methods | Customers can pay using payment methods appropriate to their market — for example ACH, SEPA, UPI, or wallets such as Wero. A single default gateway is acceptable if it provides this local flexibility; the criterion is about local payment-method coverage, not the number of gateways. |
Developer / Code Capabilities
Developer capabilities provide technical options for buyers that need greater control over how a white-label solution is built and integrated. A white-label API provides programmatic access to relevant platform functionality, while a white-label SDK provides development tools to build or integrate relevant capabilities into a branded application or experience.
An API or SDK does not automatically qualify as a white-label API capability or white-label SDK capability. Where a provider specifically documents these capabilities for white-label implementations, that documentation can be used as evidence. The assessment focuses on what the buyer can actually control or build, rather than the mere availability of developer tools.
| Capability | What we look for |
|---|---|
| White-Label API | An API the buyer can use to operate Brand and Flexibility capabilities in a white label customer offering. That can include account provisioning, branding or domain settings, workflows, roles, billing, or similar platform controls. A generic data or reporting API is not this. |
| White-Label SDK | An SDK the buyer can use to build or integrate Brand and Flexibility capabilities into a branded customer application or experience. This may include libraries, components, or abstractions that support integration and custom development. A generic REST wrapper, mobile kit, or chat/agent SDK is not this unless it is documented as a white label implementation. |
Flexibility maturity
Flexibility maturity reflects the overall extent to which the software can be adapted for a white-label offering. The assessment considers capabilities available through no-code/low-code and developer routes, either independently or in combination.
The levels are a guide rather than a strict checklist. A platform does not need every capability listed within a level to qualify. The objective is to identify the level that best represents the platform's overall flexibility and the buyer types it is most likely to suit.
| Level | Maturity | No-Code / Low-Code Route | Typical buyer fit — No-Code / Low-Code | Developer / Code Route | Typical buyer fit — Developer / Code |
|---|---|---|---|---|---|
| Level 1 | Brandable White-Label | Basic configuration and limited adaptation of the existing product, with little control over underlying functionality or customer-specific behaviour. | Branded Business | Limited developer capabilities for adapting or integrating the platform into a branded offering. White-label-specific API or SDK support may be absent or limited. | Branded Business |
| Level 2 | Enhanced White-Label | More advanced configuration, customer management, workflow customisation, and selected operational or commercial controls that help the buyer operate its own branded offering. | Branded Business, Agency, Reseller | APIs, SDKs, or related developer capabilities support meaningful customisation or integration of selected functionality and controls relevant to the white-label offering. | Agency, Reseller, SaaS Builder |
| Level 3 | Deep White-Label | Extensive configuration and customisation that can support a highly differentiated offering, potentially without requiring conventional software development. | Branded Business, Agency, Reseller | Extensive developer capabilities enable substantial control over functionality, integration, and the product experience, allowing the platform to underpin a highly customised application or broader solution. | SaaS Builder, Solution Integrator |
The two routes are not mutually exclusive. A platform can reach a maturity level through different combinations of no-code/low-code and developer capabilities. For example, a highly configurable no-code platform may provide Deep White-Label flexibility without exposing an API or SDK, while another platform may rely heavily on developer capabilities to enable extensive customisation and integration.
The buyer types are indicative rather than exclusive. The appropriate maturity level depends on the buyer's objectives and required degree of control, not simply its identity or technical resources. The presence of an API or SDK alone does not establish a higher maturity level; the assessment must consider the actual capabilities it enables.
◎ Community Signals
Community Signals are not a capability domain. They provide a complementary, real-world perspective on the capabilities above, using customer and user experiences to highlight practical strengths, limitations and dependencies that may not be apparent from provider documentation alone.
We look for specific, relevant, recent and firsthand evidence, with greater weight given to experiences that are corroborated across users or sources.
Community Signals are supporting evidence, not capability verification. They can reinforce a documented capability or highlight practical considerations that buyers should investigate further.
Click here for more on the Framework
Beyond Brand and Flexibility
Brand and Flexibility are the two domains used for the baseline review because they can generally be verified from a provider's website, product documentation and, where available, the application itself.
The framework also includes Control, Trust, and Commercial & Operations. These matter when assessing the longer-term suitability of white-label software, but they are harder to verify consistently from public information alone. They can involve sentiment analysis, data ownership, migration, security, pricing, support, infrastructure, service levels and product roadmaps.
These domains are therefore better suited to a deeper review conducted with the provider, rather than being required for every directory listing.
◈ Capability Domain 3: Control
Control measures how dependent you are on the provider. It covers areas such as data portability, migration, hosting, source-code access, ownership and what happens if the provider changes its pricing, product or ownership.
It answers:
How independent am I from the provider?
❖ Capability Domain 4: Trust
Trust considers whether the provider is reliable enough to build your business and client relationships on. It can include security, compliance, uptime, API stability, support, reputation and transparency.
As indicated above, Trust is not part of the baseline review because these factors are harder to assess consistently across a large number of software providers. However, Ahrefs Domain Rating (DR) is included on directory listings as a base external signal of the provider's online presence and authority, giving buyers additional context when evaluating a provider.
It answers:
Can I rely on the provider long term?
⊞ Capability Domain 5: Commercial & Operations
Commercial & Operations covers what is required to run the software in practice. This varies by software category and can include onboarding, data migration, billing, support, partnerships, integrations and day-to-day production operations.
It answers:
Will it work for my business in production?
The Five Domains
| Domain | What it answers | Baseline review |
|---|---|---|
| ✦ Brand | What can I present as my own? | ✓ |
| ⚒ Flexibility | How far can I adapt the software to my offering? | ✓ |
| ◈ Control | How independent am I from the provider? | — |
| ❖ Trust | Can I rely on the provider long term? | — |
| ⊞ Commercial & Operations | Will it work for my business in production? | — |
The framework is broader than the baseline review. Brand and Flexibility provide a practical way to compare a large number of software products consistently. Control, Trust, and Commercial & Operations provide additional context for buyers who need deeper due diligence before committing to a platform.
The aim is not to turn every software listing into an exhaustive procurement exercise. The baseline gives buyers a consistent starting point for understanding what a provider actually offers, identifying the appropriate white-label maturity level and buyer fit, and deciding when a deeper conversation with the provider is warranted.