White Label Boundaries, Troubleshooting, and Daily Operations

This article is the final boundary and operation checklist for the white label series: which capabilities are brand and display, which are not authorized or tenant-isolated; the order of troubleshooting when issues arise; what to check daily, weekly, and monthly.

¶ Final Acceptance Before Official Launch

¶ Brand and Page

[ ] Studio and API Platform names, logos, favicons, customer service, and legal entities are consistent;
[ ] Accessible on desktop, mobile, and incognito windows;
[ ] Studio page runs with the correct brand and records raw HTML/share preview boundaries;
[ ] Platform normal browser SPA and supported crawler SSR are accepted separately;
[ ] Shared authentication page final brand and login redirects are correct;
[ ] No menu horizontal truncation, broken images, or invalid external links.

[ ] Studio page domain HTTPS is functioning normally;
[ ] Platform page domain and deep routing are normal;
[ ] API domain can complete real minimal calls;
[ ] At least one login method completes registration, login, logout, and redirects;
[ ] DNS public queries are consistent with current console requirements;
[ ] The team knows that domain activation does not equal account or token isolation.

¶ Catalog, Pricing, and Delivery

[ ] Studio only displays capabilities ready for operation;
[ ] Platform service and documentation catalog align with business;
[ ] Overall site and single service channel pricing meet expectations;
[ ] Display currency and order settlement currency have been verified separately;
[ ] Test customers use their own independent keys;
[ ] Key deactivation, usage, and billing have been accepted;
[ ] The team knows that catalog visibility is not API authorization.

¶ Customers, Privacy, and Revenue

[ ] New test customers hit expected invitation relationships;
[ ] Small orders, limits, usage, and distribution records correspond with each other;
[ ] Customer service knows how to use request identifiers and time for troubleshooting;
[ ] Website statistics are consistent with privacy policies;
[ ] The team will not promise full refunds on price differences, fixed commissions, or fixed income.

¶ Boundaries That Must Be Clearly Stated

¶ Shared Identity, Balance, and Packages

White label is a Site configuration on a shared platform, not an independent deployment or independent database. Users can use the same shared account across different Sites; balances, packages, and most assets are not one set per Site.

¶ Display Control Is Not Authorization

The following settings only change the page display of the current site:

Hide recharge;
Hide capabilities or services;
Hide documentation or menus;
Hide login entry.

They do not revoke existing accounts, server-side authentication, shared balances, or API permissions. Security boundaries must be implemented by actual backend authorization.

¶ Channel Pricing Is Not Strong Tenant Pricing

Site markup is used to identify and record channel pricing in the normal white label browser purchasing process. It is not a mandatory tenant price that cannot be bypassed across all domains, all direct calls, and all purchase entrances.

¶ Custom API Domain Is Not an Independent Gateway

API domains are used for branded request entry; authentication, billing, and gateways are still a unified system. Valid keys will not be automatically restricted to a certain Site due to different hostnames.

¶ Brand Loading Is Divided into Two Categories

Platform provides tenant SSR for supported crawlers; normal browsers may first receive the SPA shell and then load the brand during runtime;
Studio and shared authentication pages primarily load Site brands asynchronously on the client side, raw HTML/no JavaScript clients may still be a unified product shell.

¶ Public Assets and Third-Party Statistics

Generated results may use public CDN. Enabling GA4, Baidu Analytics, Clarity, or Umami will introduce third-party data processing responsibilities, and privacy policies must be updated synchronously and verified with the official domain.

¶ Troubleshooting Order

¶ Page Won't Open

First, open the system domain;
If the system domain also fails, check Site configuration and platform status;
If only the custom domain fails, query public DNS;
After confirming DNS is correct, check HTTPS;
Record domain, time, status code, browser, and screenshots.

¶ Brand Not Updating

Confirm the current domain resolves to the correct Site;
Check for successful save prompts;
Use incognito windows to rule out caching;
Wait for the client Site configuration to load completely;
Distinguish between running DOM, normal SPA shell, and crawler SSR;
Check Favicon cache and share preview separately.

Record which page domain initiated the request;
Check if the shared authentication page loads the correct Site brand;
Check enabled methods and default methods;
After completion, confirm return to the original domain;
Do not provide passwords, verification codes, OAuth codes, tokens, or SMS secrets.

¶ API Call Failure

Use the same key to call the public API domain;
If the public domain also fails, check the key, limits, paths, and parameters;
If only the custom domain fails, check API domain status, TLS, and paths;
Record publicly request identifiers, time, paths, and status codes;
Never send complete keys or Authorization headers to customer service.

¶ Price or Revenue Discrepancies

Record customer, order, request, and time;
Verify overall site and single service markups;
Distinguish between display currency and settlement currency;
Verify if the order is completed, refunded, or under risk control;
Verify first invitation relationships and distribution levels;
Use order/usage/distribution records, do not estimate prices independently from the page.

¶ Statistics Have No Data

Confirm that statistical configuration has been enabled and saved;
Check ID format and official domain;
Check browser privacy/ad blockers;
Confirm that the current Site's domain has been activated;
Do not bypass supported configurations by pasting arbitrary scripts.

¶ Daily Operation Rhythm

¶ Daily

Check failed requests, payment anomalies, and customer tickets;
Check main promoted services and key pages;
Publish accurate announcements for confirmed issues, do not speculate on recovery times;
Check customer service links and invalid images.

¶ Weekly

Randomly check page domains, API domains, certificates, logins, and a minimal API;
Check the main promoted service prices, documentation, and public names;
Check the validity period of banners and menus;
Review new customer sources, conversions, and customer service issues;
Check website statistics and privacy notifications.

¶ Monthly

Re-run the first registration and attribution with a brand new account;
Rotate internal testing credentials;
Review terms of service, privacy policy, and customer service responsible person;
Recheck profits, refunds, distribution levels, and channel pricing;
Take offline services, login methods, banners, or external links that are not maintained.

¶ What to Provide When Contacting Support

It is recommended to provide: page/API domain name, occurrence time and time zone, path, status code, publicly identifiable request, reproduction steps, expected results, and actual results.

Please delete: passwords, verification codes, OAuth codes, complete tokens/API Keys, Authorization headers, phone numbers, payment information, administrator/inviter IDs, and internal metadata.

¶ Success Indicators

The team can sequentially locate Site, DNS, certificates, logins, APIs, pricing, and statistical issues;
Three domain names and a minimal business link have fixed inspections;
Shared accounts, display controls, channel pricing, and API domain boundaries have been documented for customers;
Customer service materials do not contain keys or personal information;
Expired banners, services, login methods, and links will be regularly cleaned up.

At this point, Studio, API Platform, customer delivery, and operational processes have formed a closed loop. Continuously using real new customers and real minimal call acceptance is more reliable than "configuring once and not looking back for a long time."

¶ Return Overview

When two product paths need to be replanned, return to the White Label Platform Overview.