“White label” can describe anything from a logo and color palette to a service relationship in which an agency sets prices, onboards clients, and handles first-line support. Those are different levels of control. A polished login screen alone does not tell an agency who sends payment notices, what appears on the checkout page, or which party the client contacts when something breaks.
Assess the specific controls: which parts of the client journey the partner can configure, which the platform handles, and what still needs confirmation. A “100% white label” label does not answer those questions. This review uses Bolten’s public partner documentation as an example. It records documented capabilities and practical verification questions; it does not claim that a live account or client journey was tested.
Domain and entry point
A client’s first encounter may be an invitation link or a sign-in page. Bolten currently documents two subdomain routes: a subdomain on a domain owned by the partner, configured through a CNAME, or a Bolten subdomain ending in bolten.io. The documentation says the partner-owned option removes “Bolten” from the URL, while the Bolten subdomain is a simpler alternative. It also lists limits: only one domain per partner and no use of a path such as example.com/crm where the root domain already hosts another site. Check the current domain configuration guide before selecting a route; provisioning instructions and timing can change.
A branded URL is useful, but it answers only the address question. It does not establish who operates the infrastructure, what appears in browser messages or email, or what the client accepts in the terms of service. Treat those as separate checks.
Workspace identity and client-specific settings
Bolten’s FAQ says partners can configure a logo, a custom domain, and a favicon. Its client customization guide describes partner-created models as preconfigured sets of brand, price, tools, and visual identity. It also says an active client’s project can be adjusted individually, including its logo and colors; changing the general model does not automatically update existing clients. See the client creation and customization guide.
For an agency, this creates two levels to govern: the default offered to new clients and the variations already approved for current accounts. Keep a record of each client’s intended logo, colors, domain, tool access, and any configuration that differs from the model. Before promising consistency, inspect a real client account at desktop and mobile sizes and confirm which surfaces inherit those settings.
Pricing and billing are different controls
Bolten’s public pages currently disagree on an operational detail. The FAQ still describes Pagar.me for the 70/30 client checkout and says the typical transfer takes 2–3 business days. The updated 70/30 guide says new eligible Brazilian partners use Stripe, with Pagar.me retained only for clients who have not migrated; Stripe funds become withdrawable under its payout schedule and card-settlement rules. The Repasse guide also places partner billing on Stripe. Treat this as a documentation mismatch: verify the payment route, fees, and settlement timing in the partner’s own account and written terms before quoting a client. Do not apply the FAQ’s 2–3-day estimate to a Stripe account. Bolten — 70/30 billing, Bolten — Repasse billing, Bolten — Partner FAQ
For the current Stripe 70/30 flow, Bolten’s guide says partner logo, icon, and colors are applied to the checkout, billing portal, Stripe communications, and invoices; the processor’s domain remains visible. That is a documented design claim for the Stripe route, not proof that every legacy Pagar.me screen or account is configured identically. Verify the exact route and inspect the client-facing flow before promising a fully branded experience.
Onboarding materials and support
Bolten maintains a documentation kit for end clients and describes it as material for the tools the client can access, without references to Bolten. That is a documented resource, not proof that every file is appropriate for every client or that an agency can edit every part. Review the material you plan to send, adapt its instructions to the client’s configuration, and remove steps for tools the client cannot access. The end-client documentation page describes the kit.
Bolten’s FAQ says the partner handles first-line support for end clients and may escalate bugs, technical issues, or unresolved questions to Bolten. This gives the agency a direct service relationship and also makes support capacity part of the operating cost. Before launch, identify how clients contact the agency, who monitors the inbox, what response expectations are agreed, and how urgent platform incidents are escalated. Do not promise a support level the agency has not staffed.
Requests, contracts, and account changes
The FAQ says an end client can request additional components in project settings; the partner receives an email and negotiates delivery details with the client. That describes a request path, not an automatic commitment to deliver the component or a guarantee about timing. Document how the agency evaluates scope, price, approvals, testing, and rollout before accepting a change.
Contracts, privacy notices, cancellation terms, data export, and account closure deserve their own review. The public material cited here does not settle every party, notice, or operational step for a particular partner-client arrangement. Read the agreements that apply to the partner account and the end client, then confirm the client’s actual screens and emails. Legal interpretation should be reviewed with qualified counsel where needed.
A practical white-label review
Before calling a service fully branded, run through this checklist with a test account or a real onboarding that the client has agreed to:
- Address: Which URL does the client use to register, sign in, and return later?
- Workspace: Which logos, colors, favicons, and client-specific settings are visible?
- Messages: What sender name, domain, and support details appear in invitations, password resets, notifications, and receipts?
- Checkout and billing: Which company and processor appear on the checkout, invoice, card statement, and cancellation screen?
- Materials: Do the instructions match the tools and settings the client actually receives?
- Support: Who receives the first request, what is the agreed response process, and how are platform issues escalated?
- Changes: How are requests scoped, approved, priced, tested, and applied to existing clients?
- Terms and data: Which agreements and privacy notices does the client accept, and how can records be accessed or exported at the end of service?
Keep evidence for each answer: screenshots with sensitive information removed, sample emails, a copy of client-facing materials, the applicable agreement, and written confirmation from the vendor when public documentation is silent. Mark a point “confirmed” only after observing the exact account or receiving current written documentation. Do not infer that a surface is branded simply because the product’s dashboard is branded.
White label as an operating model
A platform can provide a branded entry point while leaving important operational decisions to the agency. The business model comes from the whole arrangement: the partner’s control over the offer and client configuration, the partner’s responsibility for onboarding and first-line support, the billing route selected for the account, and the ability to sustain those responsibilities.
Bolten’s public documentation supports several specific claims: partner logo/domain/favicon configuration, client-specific visual adjustments, partner-set pricing subject to minimums, two collection models, client-facing documentation, and partner-led first-line support. Other details—including legacy checkout presentation, contractual terms, and the exact messages enabled for a particular account—should be checked in the relevant account and agreements rather than assumed from the “white label” label. (Bolten — Partner guide)
That distinction makes the evaluation more useful than a binary badge. A partner can decide whether documented capabilities and verified client-facing details match the service it intends to sell, and can price support, onboarding, and maintenance as real work rather than treating branding as the whole product.
