nikoksr/notify: One Go Interface for Telegram, Slack, Discord and Twenty Other Channels

The problem nikoksr/notify solves for Go services

Sending a notification from a Go program usually means picking a provider, learning its SDK, handling its authentication model, and repeating all of that the moment a second channel is needed. The README describes the origin plainly: the author needed a simple way to send notifications across different messaging platforms, and the result is a library designed for quick integration and ease of use. The target reader is a Go developer who already has an application emitting events and wants those events to land in a chat channel or an inbox without writing provider-specific plumbing for each one. The supported service table lists Amazon SES, Amazon SNS, Bark, DingTalk, Discord, Email, Firebase Cloud Messaging, Google Chat and HTTP among others, and the repository layout confirms that each lives in its own directory under service/, with a matching client library named in go.mod. That structure is the value proposition: the integration work is already done, and what remains is choosing a service and a receiver.

How the Notifier interface and UseServices actually work

The public surface is small. A service is anything implementing the Notifier interface, a message is a subject and a body string, and the library keeps a set of services that Send fans out to. The README explains the design as inspired by HTTP middlewares used in higher level libraries: you construct a service, register receivers with it, hand it to the notifier, and repeat for as many services as you like. The top-level files mirror that split. notify.go holds the Notifier type and its constructors, use.go holds the registration path, and send.go holds the dispatch logic, with a matching _test.go file for each. go.mod shows the dispatch layer pulling in golang.org/x/sync, which is consistent with sending to several services concurrently, though the README does not describe the concurrency model or what happens when one service fails while another succeeds. That gap matters more than it sounds: with several services registered, a partial failure is the normal case, and the documentation does not spell out the resulting error shape.

Installing nikoksr/notify and sending a first message

The README gives one install command. It fetches the module and its dependencies into your Go module.

go get -u github.com/nikoksr/notify

The usage example in the README builds a Telegram service, adds a chat ID as receiver, registers the service, and sends. The token and chat ID below are placeholders from that example, not working credentials.

telegramService, _ := telegram.New("your_telegram_api_token")
telegramService.AddReceivers(-1234567890)
notify.UseServices(telegramService)
_ = notify.Send(
	context.Background(),
	"Subject/Title",
	"The actual message - Hello, you awesome gophers! :)",
)

After running this, the message should appear in the Telegram chat identified by the receiver ID. Two details in the example are worth reading carefully. The error from telegram.New is discarded with an underscore for demo simplicity, which you should not copy. And UseServices is called on the package-level notifier, which the README explicitly discourages: it notes that global functions are provided for convenience, as in logging libraries such as zap, but recommends avoiding them and using a constructor function to create a local Notify instance instead. For a first run the global path is fine; for anything that runs in more than one place at a time, take the constructor.

Where nikoksr/notify is the wrong tool

The README contains a disclaimer that most libraries bury. It states that because Notify depends on the consistency of the supported external services and the corresponding latest client libraries, the authors cannot guarantee reliability or consistency, and that you should probably not use or rely on Notify in critical scenarios. That is an unusually direct statement of scope, and it should be taken at face value. If a missed page means an outage goes unnoticed, this is not the layer to build that on. The same disclaimer warns that spamming through the library may get you permanently banned on most supported platforms, which is a real operational risk for anything that loops over a user list. A second constraint is version churn: the library sits on top of provider SDKs, and go.mod pins specific versions of each, so a breaking change in a provider's API lands here as a dependency bump rather than something the library can absorb silently. The README does not document retry behaviour, rate limiting or delivery confirmation.

How it differs from wiring each provider SDK directly

The obvious alternative is to import each provider's own Go SDK and call it yourself. That path keeps you on the vendor's release cadence and gives you direct access to features the wrapper does not expose, such as message threading, attachments or delivery receipts, but you write and maintain one integration per channel and you own every credential format and error type separately. A second alternative is a hosted notification API that accepts one HTTP request and fans out to many channels on the server side. That moves the provider SDKs and their version churn out of your binary, at the cost of a network hop, a third-party dependency in the delivery path, and per-message pricing. nikoksr/notify sits between them: the fan-out logic and the provider clients are in your process and your go.sum, and the only thing you write is the service construction. The trade is that you inherit the library's dependency graph, which go.mod shows is large, including the AWS SDK v2, the Slack SDK, discordgo, the Telegram bot API client and several others.

Maintenance, licence and the cost of staying current

The repository is not archived and the last push was on 2026-09-21, two days before this writing, so the project is being worked on. Releases are less frequent than commits: v1.6.0 landed on 2026-08-31, after v1.5.0 on 2025-12-15 and v1.4.0 on 2025-12-11, which suggests that a version tag is not the unit you should track. If you depend on a fix, you may be following main rather than a release. The upgrade cost is dominated by the transitive dependencies rather than the library's own code, since every supported service drags in its provider client; the Makefile shows the project's own hygiene loop of golangci-lint, gofumpt, gci and golines, which you do not inherit. The licence is MIT, which permits commercial and closed-source use and requires the copyright notice and permission notice to be included; the README's disclaimer adds that misuse is the user's own liability. That is not legal advice, and the licence text is the authority.

Editorial conclusion

Adopt nikoksr/notify when you want one Go interface over several chat and email providers and you can tolerate the project's own caveat that it should not be relied on in critical scenarios. Do not adopt it when you need delivery guarantees, retries or an audit trail: the README states the library depends on the consistency of external services and their client libraries and that it cannot guarantee reliability. Before you commit, verify the specific service package you need exists under service/ and that the client library it wraps still matches the provider's current API, then run go build ./... and go test -failfast -race ./... against your own integration.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nikoksr/notify on GitHub
4. README
5. Releases