Transmitly 0.4.2

Let your .NET application express it's intent to communicate without doing the work in your business logic.

Transmitly is an extensible transactional communications library for .NET. It keeps email, SMS, push, voice, message composition, provider configuration, and delivery handling out of your domain and application logic.

Your application expresses an intent:

var result = await _communicationsClient.DispatchAsync(
    "WelcomeKit",
    newAccount.EmailAddress,
    new { firstName = newAccount.FirstName });

Elsewhere, Transmitly defines what WelcomeKit means: which channels are involved, how content is composed, which providers can deliver it, and how delivery events are handled.

Application
    |
    | Dispatch("WelcomeKit")
    v
Pipeline: WelcomeKit
    |
    +-- Email ----> SMTP / SendGrid / Mailgun / Infobip
    +-- SMS ------> Twilio / Infobip
    +-- Push -----> Firebase
    +-- Voice ----> Twilio / Infobip

That separation is the point of Transmitly.

When should I use it?

Transmitly is a good fit when:

• transactional communication is becoming infrastructure rather than a single SendEmail(...) call
• provider SDKs, templates, channel decisions, or webhook behavior are leaking into application code
• you have, or expect, multiple message types, channels, or providers
• you want composition and delivery behavior managed in one place
• you want provider or channel changes without rewriting the application workflow that requested the communication

When shouldn't I use it?

If your application sends one kind of email through one provider and that is unlikely to change, a small IEmailSender-style abstraction may be enough.

Three concepts to get started

• Pipeline — a domain-oriented communication intent such as WelcomeKit, PasswordReset, or OrderProcessing
• Channel — how the recipient can receive it: Email, SMS, Voice, or Push Notification
• Channel Provider — the infrastructure that delivers the channel, such as SMTP, SendGrid, Twilio, Infobip, Mailgun, or Firebase

The pipeline is the stable boundary your application talks to. Channels, providers, templates, and delivery behavior can evolve behind it.

Try Transmitly without a provider account

The core package includes simulation support, so your first dispatch does not require an SMTP server, API key, or third-party account.

dotnet add package Transmitly

using Transmitly;

var communicationsClient = new CommunicationsClientBuilder()
    .AddSimulationSupport()
    .AddPipeline("WelcomeKit", pipeline =>
    {
        pipeline.AddEmail(
            "welcome@my.app".AsIdentityAddress("Welcome"),
            email =>
            {
                email.Subject.AddStringTemplate("Thanks for signing up!");
                email.TextBody.AddStringTemplate("Welcome to the app.");
            });
    })
    .BuildClient();

var result = await communicationsClient.DispatchAsync(
    "WelcomeKit",
    "developer@example.com",
    new { });

Console.WriteLine(result.IsSuccessful);

AddSimulationSupport() uses Transmitly's built-in simulation provider. By default, it returns a successful simulated dispatch result so you can exercise the same pipeline model without sending a real communication.

Send through a real provider

When you're ready for real delivery, install only the provider your application uses. For SMTP:

dotnet add package Transmitly.ChannelProvider.Smtp

var communicationsClient = new CommunicationsClientBuilder()
    .AddSmtpSupport(options =>
    {
        options.Host = "smtp.example.com";
        options.Port = 587;
        options.UserName = "MySMTPUsername";
        options.Password = "MyPassword";
    })
    .AddPipeline("WelcomeKit", pipeline =>
    {
        pipeline.AddEmail(
            "welcome@my.app".AsIdentityAddress("Welcome"),
            email => email.Subject.AddStringTemplate("Thanks for signing up!"));
    })
    .BuildClient();

Your application still dispatches WelcomeKit. It does not become SMTP-specific.

Change providers without changing application intent

Moving email delivery from SMTP to SendGrid is a provider configuration change:

- .AddSmtpSupport(options =>
- {
-     options.Host = "smtp.example.com";
-     options.Port = 587;
- })
+ .AddSendGridSupport(options =>
+ {
+     options.ApiKey = "MySendGridApi";
+ })

After installing Transmitly.ChannelProvider.SendGrid, the pipeline and calling application can remain unchanged.

The ecosystem is modular by design

Most applications need the Transmitly core package, one or more provider integrations, and optionally a template integration.

Channel providers

Channel(s)	Integration	Package
Email	SMTP	Transmitly.ChannelProvider.Smtp
Email	SendGrid	Transmitly.ChannelProvider.SendGrid
Email	Mailgun	Transmitly.ChannelProvider.Mailgun
Email, SMS, Voice	Infobip	Transmitly.ChannelProvider.Infobip
SMS, Voice	Twilio	Transmitly.ChannelProvider.Twilio
Push Notifications	Firebase	Transmitly.ChannelProvider.Firebase

Optional integrations

• Microsoft.Extensions.DependencyInjection
• ASP.NET Core MVC and AspNet.Mvc for provider webhook/delivery-report integration
• Fluid and Scriban for dynamic template rendering

Literal/string message content can be configured directly in core. Dynamic template rendering is deliberately pluggable so you can choose the engine that fits your application.

Delivery reports

Transmitly provides a consistent delivery-report model so application-level handling does not have to become provider-specific. Third-party providers commonly send later status updates through webhooks; the optional MVC integrations can route those provider-specific payloads into Transmitly's delivery-report handling.

• Delivery reports documentation
• ASP.NET Core MVC integration
• AspNet.Mvc integration

Compatibility

The core project currently targets:

• .NET 10
• .NET 9
• .NET 8
• .NET 6
• .NET Standard 2.0
• .NET Framework 4.8 and 4.7.2

Project status

Transmitly 0.4.0 is production-ready and in production use.

There are additions and refinements planned before 1.0, and the project still reserves room for API evolution while that work lands.

Samples and documentation

• Samples
• Hello Transmitly sample
• Kitchen Sink sample
• Microservices sample
• Wiki

Feedback wanted

If you try the quick start and something is confusing, overly abstract, missing, or simply not worth the ceremony, please tell us in GitHub Discussions. API criticism, onboarding friction, unsupported workflows, and "I stopped here because this didn't make sense" are all useful feedback.

For larger proposed changes, starting with a Discussion is the best way to align before implementation.

License

Licensed under the Apache License, Version 2.0.

Copyright (c) Code Impressions, LLC