White-label WooCommerce app builder: what's in, what's out
By Abdalla Kamesh · Published October 19, 2026 · 7 min read
“White-label” is one of the most overclaimed words in app building. A vendor writes it on the pricing page, an agency repeats it in a proposal, and three months later a client asks why the login page has somebody else’s name on it. This post takes the word apart into the six things agencies usually mean by it, and says for each one what StoreToNative does today, in plain yes and no. Two of the six are a no, by decision, and the reasons are below.
It is written by the vendor, so treat it as a checklist to verify against the Agency plan and the console, not as a promise. If you are still deciding whether to offer apps at all, start with adding mobile apps to your agency services and come back here for the branding question.
The six things “white-label” usually means
| What the agency means | StoreToNative today |
|---|---|
| The console shows our logo and name | Yes |
| Invitation emails go out under our name | Yes, the sender name and the text; the address is ours, see below |
| The client report carries our brand | Yes |
| The client gets a read-only login | Yes |
| The console lives on our own domain | No, by decision |
| Emails come from our own domain | No |
Now each one, with the detail a client will ask about.
1. Console logo, name, color and font: yes
On the Agency plan, Settings has a White-label console card. You rename the platform (up to 24 characters), pick a console color from presets or a custom picker, choose a font from a preset list, and upload your logo. Everyone you invite sees the result: your logo replaces ours in the console sidebar and in the browser tab icon, and your name is in the tab title. Only owners and admins can change it, because it is the identity of the whole workspace, not one app’s design.
Two edges worth knowing. Below Agency the controls are visible but inert. And if a workspace later moves to a lower plan, it keeps the brand it already set; a downgrade never quietly puts our name back on a console your clients are used to. The help page is Team and settings.
2. Invitation emails under your name: yes, with one honest footnote
When you invite a colleague or a client from a white-labelled workspace, the email says “Join
The footnote: the address the mail is sent from is ours. Your name is on the envelope, our domain is under it. That is the same fact as item six below, and it is better to tell the client up front than to have them notice the address.
If email is not configured for your workspace, the console hands you the invitation link to forward yourself, which is the most white-label option of all.
3. A client report under your brand: yes
Each app can have a monthly client report: one link you send your client, showing a month’s figures beside the previous month, and the best sellers. The page header carries your platform name, your color and your logo, and the footer says it was generated by your platform name. Nothing on the page names us. It is self-contained, with no outside styles, scripts or fonts, because it is opened by people who are not our users, on networks we know nothing about, and it is often printed.
One more honest edge: the link itself lives on our API address, in the same way the console does. The page is yours, the web address is ours. The link is a secret token; rotating it is how you revoke it, so a lost link is replaced rather than recovered.
4. A read-only client login: yes
Agency includes ten seats, counting you. Roles are Owner, Admin, Editor and Client. A Client is invited to specific apps and sees only those apps, and only their Dashboard, Push and Analytics pages. They cannot change anything: read-only is enforced on the server for every route, not hidden in the interface, so a client with a browser’s developer tools open is no better off than a client without them.
This is the part of white-label that does the most work in practice. A client who can log in and see their own numbers under your brand stops emailing you for screenshots.
5. Your own console domain: no, by decision
The console lives at app.storetonative.com, for your team and your clients alike, and the sign-in page is ours: before someone signs in, the console does not yet know which workspace they belong to, so there is nothing to brand it with. A custom domain per agency is infrastructure work (hosting, cookies, cross-origin rules) and we have decided not to build it for now.
The honest alternative when a client asks “is this platform yours?”: the console they log in to carries your brand and lives at our address, and the app on their customers’ phones is entirely theirs. Most clients care about the second half far more than the first. Write it into the proposal and nobody is surprised later.
6. Your own sending domain: no
Follows from the above. Invitation emails are sent from our address with your name on them. Sending from your own domain would be mail infrastructure set up per agency, and it is not built.
What the client’s shoppers see
This is the question that matters most to the client, and the answer is the cleanest one in the post. Inside the app itself, there is nothing of StoreToNative on a paid plan. The app is the store’s: the store’s name, icon, colors, catalog and account, published under the store’s own developer accounts.
The one exception is the “Made with StoreToNative” badge, a small pill in the corner of the app. It shows while the workspace has not paid: during the 14-day trial, which starts with a card but is not a payment, and on an unpaid workspace. Any paid plan removes it with no rebuild; the app fetches the change on one launch and shows it on the next, so allow a launch or two. It comes back the same way if the subscription ends. It does not come back while a card is merely failing and being retried, because the badge is shopper-facing and a billing hiccup should not show up on a shopper’s screen.
So in a proposal: “the app carries no vendor branding on a paid plan” is true, and “the trial app carries a small vendor badge” is the sentence to add next to it.
The signing key and the listing: who holds what if you part ways
Agencies rarely ask this question before signing a client and always ask it after. Here is the split.
The listing and its reviews are the client’s. Each app is published under the client’s own Apple Developer and Google Play accounts, with the client’s business as the seller, and the console walks your team through both submissions as the client’s team. Apple’s Guideline 4.2.6 is the reason: apps built with an app-generation service must be submitted by the provider of the content, which is the store. If the client ever moves on, the listing, the ranking history and the installed base stay with them. Switching app builders without losing installs is the post to hand a client who asks what a change of vendor would mean.
The iOS signing is the client’s already. For the App Store you paste an App Store Connect API key and a push key from the client’s own Apple account into the console, and certificates and signing are handled from there. The client owns that account, so they own that side.
The Android signing key lives in the workspace that built the app. Every app gets its own Android upload key, created on its first build, and on the Agency plan that workspace is yours, not the client’s. The key can be exported from the Publish page by an owner or admin, after re-entering the account password, on any plan, trial included, and it stays exportable even if the plan has lapsed. It is deliberately not a plan feature. So when a client leaves, the hand-over is a file you export and pass on, and it belongs in your agreement from day one. Publish to Google Play has the export steps and what to keep safe.
Put together: the client holds the accounts and the listing, you hold the console and, until you hand it over, the Android key. Said plainly in the proposal, that is a reason a client trusts you, not a reason they hesitate.
The checklist: questions to ask any vendor before you promise white-label
Ask these of any app builder, including us, and write the answers into the client proposal.
- Whose logo is in the console, and where exactly? Sidebar, tab icon, tab title, or only one of them.
- What do invitation and system emails say, and what address do they come from? Sender name and sender domain are two different answers.
- Can the client log in, and what can they break? Ask whether read-only is enforced on the server or only hidden in the menu.
- What is the console’s web address, and what does the sign-in page look like? This is where most “white-label” claims quietly end.
- Does the client report carry my brand, and does its footer name the vendor?
- What do shoppers see inside the app on a paid plan, and on the trial? Ask about a badge, a splash screen and the app’s “about” text.
- Which developer accounts is the app published under? If the answer is the vendor’s, the listing and the reviews are the vendor’s too.
- Who holds the Android signing key, can it be exported, and on which plans? A key that cannot leave is a client that cannot leave.
- What changes without a new build? Theme, layout and content should reach installed apps over the air, within a launch or two, with no rebuild and no store re-review.
- What happens to all of the above if the plan lapses? Branding, links already sent, and the exported key should survive it.
If an agency only wants to recommend a platform rather than run the apps, the partner program is the other route, and it needs no white-label at all: the store signs up directly and you are paid for the referral.
Related reading