How to route different project events to different channels
Set up separate Telegram, Discord, and Slack routes for one project’s confirmations, rollbacks, and outgoing transfers.
Updated:
One Cryptanio project can send different events to several connected channels. Each connection has its own route and set of event types. For example, the team receives confirmed incoming payments in Slack, while the responsible staff member receives outgoing transfers and rollbacks in Telegram. You do not have to split addresses into new projects just to use different recipients.
This guide assumes the channels are already connected to the account. Creating connections is covered separately: Telegram, Discord, and Slack. Here, the task is to decide which events of an existing project to send to each recipient and check the scope of inherited settings.
Plan your recipients
Write down each channel’s purpose and required events. For example: the work Slack channel receives confirmed incoming payments and their rollbacks; the responsible person’s Telegram receives confirmed outgoing transfers. Choose channels with appropriate membership: messages may contain an amount, asset, address, and transaction identifier.
You need permission to change project notifications and active account connections. For wallet events, monitoring must also cover the required address, network, asset, and direction. Configuring recipients does not add addresses or expand network availability.
1. Check project inheritance
Open “Notifications” for the relevant project and check its name. “Use account notification settings” is at the top. When inheritance is enabled, shared routes apply and project-specific editing is locked. “Account settings” opens the shared connections and settings.
Turn inheritance off to use your own routing setup. If the project has no saved custom set yet, Cryptanio copies the shared settings, including routes. Inspect the resulting list first: the connection you need may already be added. When returning to previously saved custom settings, do not expect a fresh copy of the shared set.
A new Telegram, Discord, or Slack connection is also added to shared account notifications. Turning inheritance off for one project does not stop messages to that channel for other inheriting projects. If recipients must be separated between projects, check each project: changing one card does not guarantee account-wide isolation.
2. Add the required routes
Find the work connection in the Slack card. If its route is absent, click the plus button “Use … for this project”. If it is already present, go straight to event selection. Find the Telegram or Discord connection in the same way. One project can use several connections, including multiple connections to the same messenger.
The connection name helps distinguish the work channel from another recipient. If the connection you need is missing, create it in account settings using the separate guide, then return to the project. Do not enter Discord or Slack URLs in the Webhook card: that card is intended for your application server.
3. Select events for each recipient
For the work Slack channel, select “Confirmed and rolled back”. This policy includes confirmed incoming payments and their rollbacks. If you only need confirmations, use “Confirmed payments”. The reference article explains the difference between detection and confirmation.
For the responsible person’s Telegram, select “Choose event types” and check “Outgoing transfer confirmed”. Add “Outgoing transfer rolled back” if needed. The confirmed-payments policy does not automatically include outgoing transfers: they have their own event types.
“All project events” suits recipients who need a broad stream. It is not restricted to a single address or token. Event selection in a route is not an amount filter: monitoring assets, directions, and thresholds are configured in address rules.
4. Check saving and pauses
Adding a route and changing event selections are saved when you perform the action; these routes have no separate overall save button. Wait for the result and check the state. To stop delivery temporarily, pause the relevant route. Pausing the connection in account settings affects every route that uses it.
Removing a route with the trash button removes that recipient from this project. “Disconnect” in account settings disables the connection itself for every project that used it. These actions do not delete addresses or event history.
5. Check routing with new events
Wait for a new matching transaction and find it in “Events”. In “Deliveries”, match the event ID, project, and channel. In this example, a confirmed incoming payment should go to Slack, while a confirmed outgoing transfer should go to the selected Telegram chat. Make sure another active rule does not send the same event to an additional recipient.
The connection’s “Test” button sends a separate test notification and does not prove that the event policy is correct. Enabling a route does not replay past history. If an event exists but no expected delivery was created, check the policy, inheritance, and pauses. If a delivery was created, investigate its result separately; changing recipients does not by itself confirm payment of an order.