Ask ten people who run software how their integrations broke and eight will describe the same thing. A key was pasted on one screen in March. In June somebody pasted a different key on another screen for the same service. Both saved. Neither was wrong on its own. Reports went quiet for three weeks before anyone worked out which of the two was actually being used.
Scalegram answers that with a rule rather than a feature. There is one Integrations page. Everything that requires a credential, an authorisation or a piece of external plumbing connects there, once. Every other screen in the product picks from what is already connected and cannot create a connection of its own.
What actually lives on that page
The page is the boundary between Scalegram and the outside world, so the list is longer than a settings screen usually is:
- Telegram bots, and the Telegram Business connection that lets an assistant answer your own profile.
- Advertising pixels for the conversion events the product fires, along with their server-side API tokens.
- Custom domains for bridge landing pages, so a page runs on your own hostname rather than ours.
- The Whop connection that pulls completed sales back into the client list, described in purchase sync.
- A broker affiliate API connection, where the broker publishes one, for checking that an account under your link exists and has been funded.
- Your own AI key, since the model that drives the assistant is yours and not resold by us.
Read that list back and you have a fair description of the product's surface area. A bot to speak through, a pixel to report to, a domain to host on, a checkout and a broker to verify against, and a model to think with. Everything else in Scalegram is built from those six things.
Saving a key is not the same as it working
The worst behaviour a settings screen can have is to accept a credential, colour the row green, and tell you nothing further until a customer complains. A saved key and a working key are different states, and the gap between them is where quiet failures live: a token that was revoked, a scope that was never granted, a value pasted with a trailing space.
So the page tests what you give it. You paste, it saves, and then it goes and asks the real service whether the credential is any good, reporting back what the service actually said rather than the fact that a database row was written. When a connection later stops working, the same test is one click away, which means the first diagnostic step for anything broken is always the same screen.
Secrets are write-only after the first save. You can replace a token, you cannot read one back out of the interface, and neither can anyone you invite into the workspace. That is deliberate, and it is the same reasoning as in what a customer can never extract: the safest place for a secret is one nobody can copy out of.
Why every other screen only selects
Once connections exist in exactly one place, the rest of the product gets simpler in a way users feel without noticing. The tracking-link editor asks which pixel to fire, not for a pixel ID. A bridge page asks which domain to sit on, not for DNS instructions. A bot's flow asks which broker connection to verify against, not for an API secret.
The point is not tidiness. It is that a selection cannot drift out of sync with a credential, because there is only ever one credential to drift from. Change a token on the Integrations page and every link, page and flow that referenced that connection keeps working, with no hunt for the six other places the old value was typed.
The inverse failure is easy to picture. Give five screens the ability to hold their own copy of a Whop key and you will eventually have two half-configured Whop connections, one of which fires conversion events and one of which does not, and no obvious way to tell which is which from inside the reports.
Who in your team should touch it
Integrations sit at account scope, above any individual bot or campaign, so the page is usually the first thing an owner locks down. A media buyer needs to choose a pixel on a link. They do not need to be able to replace the token behind it, and they certainly do not need to disconnect the broker API on a Tuesday afternoon. Permissions in Scalegram are set per area with separate read, add, write and delete rights, and Integrations is the area where the difference between read and write matters most.
The practical setup for a small team: the owner and one trusted operator hold write on Integrations, everyone else holds read so they can see what exists and select it. That preserves the rule that makes the whole design work, which is that there is exactly one hand on the plumbing.
What it does not hold
Two things stay off the page permanently. Card details never reach Scalegram, because checkouts stay with the processor that took the payment and only the completed sale comes back. And the text of your Telegram conversations is not stored anywhere in the product, connected integration or not, which is a design decision covered in the product overview and one that no integration can quietly reverse.
The scope rules for account-level connections, including which settings genuinely belong to a single bot instead, are set out in account level integrations.
"If a key can be pasted in two places, one day it will be, and you will find out from a client rather than from a dashboard. One screen writes, everything else reads."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Every credential, bot, pixel, domain, checkout and broker connection in Scalegram is created on a single Integrations page.
- Pasting a key saves it and then tests it against the real service, so a green row means the service answered, not that a row was written.
- Secrets are replace-only after saving; nobody in the workspace can read a stored token back out.
- Other screens select from existing connections instead of holding their own copies, so a token change never has to be repeated in six places.
Frequently Asked Questions
Can I connect more than one bot or pixel?
Yes. The page holds multiple connections of the same kind, and each link, page or flow picks the one it should use. Agencies commonly run one pixel per client this way.
What happens to my links if I replace a token?
Nothing breaks. Links and pages reference the connection, not the secret inside it, so replacing a token on the Integrations page updates every place that connection is used.
Why can I not view a key after saving it?
Because a readable secret is a copyable secret. You can replace a credential at any time, and the self test tells you whether the current one works, which is the question you actually need answered.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.