Renting a panel involves a few settings a service could flip on for you, but shouldn't. The two most visible ones are Telegram notifications and Google sign-in. In both cases the right answer is the same: the bot and the app must be yours, not the service's. Here's why, and what you have to do by hand.
The problem with one shared bot
Picture this: a customer places an order on a panel with your domain, your logo and your name — and the order notification arrives from a bot named after the rental service. In one second they learn the panel isn't yours, it's rented, and someone else stands behind your sign.
That's exactly what white-label is supposed to prevent. Domain, logo, colours and emails can be perfect, and one message from a foreign bot undoes all of it. So panel notifications run on the tenant's bot: your customers and you receive messages from your bot under your name.
Your own bot: a minute of work
Technically it's simple, and it's the one step nobody can do for you.
- Create the bot. In Telegram, @BotFather asks for a name and a handle and hands you a token.
- Paste the token into panel settings. It's stored encrypted; neither we nor your customers need to see it.
- Register the webhook. A button in the settings — the panel tells Telegram where to deliver messages.
Give the bot your avatar and description right away: customers see its name in every notification, so it's part of the brand rather than a technical detail.
Google sign-in: why one app can't cover everyone
Here the reason isn't branding but how the mechanism works. Google only accepts pre-registered redirect addresses: a list of domains it agrees to return a user to after authorisation. Panels live on their owners' own domains, and registering them all in one app up front is impossible — a new domain appears every time a new panel is connected.
So Google sign-in runs on the tenant's keys: you create a project in the Google console, get a client id and secret, and paste them into the panel settings. The keys are stored encrypted. You also own the app, which means the consent screen shows your name rather than someone else's.
The downside, stated honestly: it's several steps in the Google console and they aren't the friendliest. Instructions sit right on the setup page, but this won't be a thirty-second job like the bot. If you don't need Google sign-in, simply leave it off — ordinary email signup always works.
What stays on the service's side
Not everything moves to your keys. The panel core, certificates, availability, updates and default email delivery stay with us. Our own bot hasn't gone anywhere either, but it has a different job: it notifies you about rental matters — invoices, panel status — and it never messages your customers.
The split is simple: everything the tenant's customer sees is branded as the tenant; everything about the rental comes from us and only to you.
The general rule: whoever owns the keys owns the brand
It's worth applying that rule to every external integration you attach to a panel.
- Payment methods — on your accounts: money should reach you directly, and your name should appear on the customer's statement.
- Service providers — on your API keys: your prices and your purchase terms, with nobody standing between you and the provider.
- Analytics counters — yours: traffic data stays with you.
- The domain — registered to you. That's what makes the whole arrangement yours rather than rented.
Wrap-up
White-label is more than a logo in the header. It breaks on small things: a foreign bot name in a notification, a foreign name on a sign-in screen, foreign details on a bank statement. That's why the integrations a customer sees run on your keys, and setting them up takes minutes when you connect the panel. Seeing how it looks in finished form costs nothing: while third-party orders stay under a hundred a month the rent is zero, and on our own catalog the panel is free at any volume.
