Run two Telegram bots for two offers and a question appears on day one: does the second bot need its own copy of everything? Its own pixel, its own Whop connection, its own broker key, its own domain? Answer that badly and setting up bot number three takes as long as bot number one did, forever.
Scalegram draws the line at the account. Anything that represents a relationship between your business and an outside service belongs to the account and is configured once. Anything that represents how a particular bot speaks or behaves belongs to that bot.
What sits at account level
The account holds the external relationships. Your advertising pixels and their server-side tokens. Your Whop connection. Your broker affiliate API connection. Your custom domains. Your AI key. None of those are properties of a bot. You do not have a different Whop account for your Spanish funnel, and a broker does not issue you a second affiliate identity because you launched a second bot.
The test is simple enough to apply yourself. If you would describe the thing to an accountant as belonging to the company rather than to a campaign, it is account level.
What stays with the bot
The bot keeps its own voice and its own job. Which flow blocks run, what the greeting says, which saved replies and files it can send, which language rules apply, what its ask-me checkpoints stop for, which pixel connection it reports to and which broker connection it verifies against. Notice the last two: the bot chooses, the account owns. That distinction is the whole architecture in one sentence.
It also means a second bot is cheap to create. You give it a personality and point it at connections that already exist. Nothing is pasted twice, and the second bot inherits a tested pixel rather than a freshly pasted one nobody has fired an event through yet.
One write path, many read paths
The rule that keeps this honest is that writes only happen in one place. Connections are created and edited on the Integrations page and nowhere else in the product. Every other screen has read access to the list and can select from it, but cannot add to it, edit it or quietly create a duplicate while you are configuring something else.
Software teams will recognise this as an ordinary discipline applied to a user interface. It is worth stating because the alternative is so common. Most tools let you paste a pixel ID on the campaign screen because it feels helpful in the moment, and then spend the next two years fielding tickets from customers with four pixels named "pixel" and no memory of which one their best campaign was using.
The migration case, which is where it earns its keep
Businesses change providers. You move to a new advertising account, rotate a broker key after a staff change, or switch the domain your bridge pages run on. At account scope that is one edit and one self test. The bots keep pointing at the same named connection, which now holds a different secret behind it, and the change takes effect everywhere at once.
At per-bot scope the same change is a sweep. Ten bots, ten edits, and a real chance that bot seven is missed and keeps firing to a dead token for a month. Because conversion events fail quietly by design, nothing on your screen turns red while that happens. You find out when a media buyer notices the purchase count is thin, which is several thousand in spend too late.
Account scope is also a compliance boundary. Because there is one place to look, the honest answer to "which external services hold data about our clients" is a single screen anyone senior can read, rather than an archaeology project across every bot in the workspace.
Permissions follow the same line
Once integrations are account property, they need account-level control over who touches them. Scalegram sets permissions per area with separate read, add, write and delete rights, so a setter can be given read on Integrations and full rights on the client list, while the ability to replace a broker key stays with whoever is accountable for the money. The details are in teams and per area permissions.
The same logic runs through the reporting side. A synced purchase carries the campaign identifiers captured at the landing page and is claimed once no matter how often a sync repeats, which only works because there is one connection producing it rather than several racing each other. That mechanism is covered in purchase sync.
Where the line is genuinely arguable
Not everything sorts cleanly. A custom domain is account property, but a bridge page on it is not, and teams that run one domain per client wish domains were scoped tighter. Language handling is bot-level in practice, since a bot answers in the language the customer wrote in, but the model key behind it is shared. We have taken positions on these rather than adding a toggle for each, because a scope setting that users can flip is a scope setting that will eventually be flipped by accident.
If your structure needs genuinely separate accounts, for instance an agency holding client work apart, separate accounts are the answer rather than per-bot keys inside one account. Current plan details for that are on scalegram.io.
"Ask whether the thing belongs to your company or to one campaign. Companies own pixels and broker keys. Campaigns own words. Put each where it belongs and your tenth bot takes ten minutes."
— Alex Onta, Executive Director, SINGUARD
Key Takeaways
- Pixels, checkout accounts, broker affiliate APIs, custom domains and your AI key belong to the account and are configured once.
- Flows, greetings, saved replies, language behaviour and checkpoint rules belong to the individual bot, which selects the account connections it uses.
- Connections can only be created or edited on the Integrations page; every other screen reads and selects.
- Rotating a credential is one edit at account scope instead of a sweep across every bot, which is where per-bot keys quietly fail.
Frequently Asked Questions
If two bots share one pixel, can I still tell their results apart?
Yes. Events carry the campaign identifiers captured at the click, so reporting separates by campaign and link rather than by which bot fired the event. Sharing a connection does not merge the numbers.
Can one bot use a different broker connection from another?
Yes. Multiple broker connections can exist at account level and each bot selects the one it verifies against. The bot chooses; the account owns the credential.
What if I want completely separate setups for two clients?
Use separate accounts. Per-bot credentials inside one account would give you separation on paper and shared blast radius in practice, which is the worst of both.
About the Author
Alex Onta is an Executive Director at SINGUARD. He built eTrader, the terminal, the mobile apps, eTrader Broker, Copytrading, Business and Community, along with the worldwide clustered-server infrastructure it all runs on, with his brother Roman Onta helping on the design, and he leads that division today. Together with Roman he builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals, and the two of them carry worldwide compliance, payment processing and international business structuring side by side. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.