Notifications & Telegram
Alerts about your own deployed strategies, delivered to Telegram. Opt-in, revocable, and, the part that matters, not trade recommendations.
What you get told about
| Event | Example |
|---|---|
| Fills | An entry or exit filled |
| Rejections | An order was rejected, with the reason code |
| Risk breaches | A gate tripped, which rule, current value, limit |
| State changes | The strategy paused, stopped, or moved out of approval-pending |
| Exposure alerts | Position or symbol exposure crossed a configured level |
A notification saying a strategy entered a position is a statement of fact about something that already happened on your account. It is not a suggestion to trade, and no notification will ever tell you to buy or sell anything.
Stretus does not operate a signal service. See What Stretus is not
Connecting Telegram
Why it works the way it does
The Telegram Bot API gives the platform no way to reach a user it has not spoken to. There is no send-by-phone-number, and a chat id only exists once you have started the bot.
So connecting is necessarily user-initiated, and the only thing tying the resulting chat back to
your account is a token the platform mints and you carry into the conversation through a t.me deep
link.
The flow
- Profile > Notifications > Connect Telegram
- The platform mints a single-use connect token and builds a deep link
- Open the link. It starts a chat with the bot
- Press Start; the token is redeemed and the binding is created
- A confirmation message arrives in the chat
The token is a bearer credential
That deep-link token can claim someone's notifications, so it is treated as a credential rather than a convenience:
| Property | Why |
|---|---|
| Random | Not guessable |
| Hashed at rest | The stored form cannot be replayed |
| Short-lived, 15 minutes | Long enough to switch apps and press Start; short enough that a link left in a screenshot or a chat history is dead by the time anyone finds it |
| Single-use | Redeemed once |
| Superseded on reissue | Requesting a new link invalidates the old one |
Anyone who opens it before you do binds their chat to your account and receives your strategy notifications. If you think a link leaked, request a new one, issuing supersedes the old.
If the bot is not configured
The feature is unavailable rather than half-working. A link the platform cannot build is worse than a clear "not configured".
Revoking
Three ways, all of which take effect immediately:
| Action | Effect |
|---|---|
| Disconnect from Profile | Binding revoked |
| Block or remove the bot in Telegram | Binding revoked automatically, with the reason recorded |
| Reconnect a new chat | The prior binding is revoked with reason reconnected |
A binding carries a status, so the platform can distinguish never connected from disabled from revoked. The audit row is retained after revocation, the record of the binding survives, the delivery does not.
Telegram as signal ingress
The same integration works in the opposite direction for remote strategies: you can send signals in from a bound chat.
That is a different feature with the same transport, and it has its own authentication, its own per-chat and per-strategy rate limits, and its own decision taxonomy:
| Decision | Meaning |
|---|---|
accepted | The signal was taken |
duplicate | Deduplicated |
rejected | Refused |
no_signal | The message contained no parseable signal |
parse_error | Malformed |
no_binding | The chat is not bound to a strategy |
disabled / revoked | The binding is not active |
rate_limited | Over the per-chat or per-strategy limit |
live_not_enabled | Live execution is not enabled for that path |
connected / disconnected | Binding lifecycle events |
Every decision is recorded with the chat id, the decision, and a hash of the payload.
The webhook returns 2xx even for a rejected signal, deliberately, so Telegram does not retry-storm a decision that has already been made. It returns 5xx only on a transient platform-side failure.
Read the bot's reply and the strategy's event timeline. Not the HTTP status. See Telegram ingress.
Choosing what to be told
Configure alerts from the strategy detail page. The events worth enabling on a live strategy:
| Enable | Because |
|---|---|
| Rejections | A rejected order is often a credential or funding problem, and an exit that cannot place is the worst case |
| Risk breaches | You want to know the moment a gate stops your strategy entering |
| State changes | A strategy that paused itself is a strategy you should look at |
Fills are optional and can be noisy on a short-timeframe strategy.
What notifications are not
| Not | Because |
|---|---|
| A substitute for monitoring | Delivery is best-effort. A missed notification is not an absence of events |
| A risk control | A notification reports; it does not pause, close or unwind anything |
| Trade advice | They describe your own strategies' activity |
| Guaranteed delivery | Telegram is a consumer messaging platform |
Message delivery is best-effort, ordering is not guaranteed under load, and the account is only as secure as the device it is signed in on.
Do not rely on a notification arriving. For anything where a missed event matters, watch Live Terminal or My Strategies.
Next
- Monitoring
- Alerts & breaches
- Remote strategies, the ingress direction
- Data, custody & security