DEV Community: Madusanka Bandara

Mastering Database Interceptors in .NET Core Web API (Beginner to Hero)

Madusanka Bandara — Tue, 02 Sep 2025 15:19:14 +0000

1. Introduction

When building modern .NET Web API applications, database operations are at the heart of everything. But have you ever wondered:

What SQL queries are being executed?
How can I log or measure query performance?
Can I stop dangerous commands before they hit the database?

The answer lies in database interceptors.

In this article, we’ll explore database interception in Entity Framework Core (EF Core) across .NET 6, 7, 8, and 9.
We’ll start at a beginner level (just logging queries) and work our way up to hero-level scenarios like performance monitoring, auditing, and blocking harmful SQL.

2. Prerequisites

A working .NET 6, 7, 8, or 9 Web API project
Basic knowledge of Entity Framework Core

Installed EF Core NuGet packages:

Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.SqlServer

3. Beginner Level: Setting Up a Web API with EF Core

Let’s start with a simple User entity and DbContext.

public class User
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

    public DbSet<User> Users { get; set; }
}

In Program.cs, register the context:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

var app = builder.Build();

app.MapGet("/users", async (AppDbContext db) => await db.Users.ToListAsync());

app.Run();

4. Creating a Simple Logging Interceptor

An interceptor lets us hook into SQL commands before they are sent to the database.

using Microsoft.EntityFrameworkCore.Diagnostics;
using System.Data.Common;

public class LoggingInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<DbDataReader> ReaderExecuting(
        DbCommand command, CommandEventData eventData, InterceptionResult<DbDataReader> result)
    {
        Console.WriteLine($"[SQL LOG] ReaderExecuting: {command.CommandText}");
        return base.ReaderExecuting(command, eventData, result);
    }

    public override InterceptionResult<int> NonQueryExecuting(
        DbCommand command, CommandEventData eventData, InterceptionResult<int> result)
    {
        Console.WriteLine($"[SQL LOG] NonQueryExecuting: {command.CommandText}");
        return base.NonQueryExecuting(command, eventData, result);
    }
}

5. Intermediate Level: Measuring Performance

We can go beyond logging and measure query execution time.

using Microsoft.EntityFrameworkCore.Diagnostics;
using System.Data.Common;

public class PerformanceInterceptor: DbCommandInterceptor
{
    public override DbDataReader ReaderExecuted(
        DbCommand command, CommandExecutedEventData eventData, DbDataReader result)
    {
        var elapsed = eventData?.Duration.TotalMilliseconds ?? 0;
        Console.WriteLine($"[PERF] Query took {elapsed} ms. SQL: {Truncate(command.CommandText)}");
        return base.ReaderExecuted(command, eventData, result);
    }

    public override int NonQueryExecuted(
        DbCommand command, CommandExecutedEventData eventData, int result)
    {
        var elapsed = eventData?.Duration.TotalMilliseconds ?? 0;
        Console.WriteLine($"[PERF] NonQuery took {elapsed} ms. SQL: {Truncate(command.CommandText)}");
        return base.NonQueryExecuted(command, eventData, result);
    }

    private string Truncate(string s, int len = 200) =>
        string.IsNullOrEmpty(s) ? s : (s.Length <= len ? s : s.Substring(0, len) + "...");
}

6. Advanced Level: Blocking Dangerous SQL

What if someone accidentally writes a DELETE without WHERE? We can block it!

using Microsoft.EntityFrameworkCore.Diagnostics;
using System.Data.Common;

public class SecurityInterceptor : DbCommandInterceptor
{
    public override InterceptionResult<int> NonQueryExecuting(
        DbCommand command, CommandEventData eventData, InterceptionResult<int> result)
    {
        var sql = (command.CommandText ?? string.Empty).TrimStart();

        // Case-insensitive check and ignore leading comments/whitespace
        if (sql.StartsWith("DELETE", StringComparison.OrdinalIgnoreCase)
            && !sql.IndexOf("WHERE", StringComparison.OrdinalIgnoreCase).Equals(-1) == false) // no WHERE present
        {
            // Block dangerous DELETE without WHERE
            Console.WriteLine("[SECURITY] Blocked dangerous DELETE without WHERE.");
            throw new InvalidOperationException("Blocked dangerous DELETE without WHERE clause.");
        }

        return base.NonQueryExecuting(command, eventData, result);
    }
}

7. Hero Level: Auditing User Actions

We can use interceptors for auditing who ran which query.

using Microsoft.EntityFrameworkCore.Diagnostics;
using Microsoft.AspNetCore.Http;

public class AuditSaveChangesInterceptor : SaveChangesInterceptor
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public AuditSaveChangesInterceptor(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public override InterceptionResult<int> SavingChanges(DbContextEventData eventData, InterceptionResult<int> result)
    {
        var userName = _httpContextAccessor?.HttpContext?.User?.Identity?.Name ?? "anonymous";
        Console.WriteLine($"[AUDIT] User '{userName}' is calling SaveChanges at {DateTime.UtcNow:O}");
        return base.SavingChanges(eventData, result);
    }
}

8. Registering the Interceptor in `Program.cs`

Program.cs (minimal hosting; ensure interceptors are registered as IInterceptor)

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Diagnostics;
using Microsoft.Extensions.Logging;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddHttpContextAccessor();

// Register interceptors as IInterceptor so GetServices<IInterceptor>() returns them
builder.Services.AddScoped<IInterceptor, LoggingInterceptor>();
builder.Services.AddScoped<IInterceptor, PerformanceInterceptor>();
builder.Services.AddScoped<IInterceptor, SecurityInterceptor>();
builder.Services.AddScoped<IInterceptor, AuditSaveChangesInterceptor>();

// Add DbContext and inject resolved interceptors into EF Core options
builder.Services.AddDbContext<AppDbContext>((serviceProvider, options) =>
{
    var connectionString = builder.Configuration.GetConnectionString("DefaultConnection") ??
                           "Server=(localdb)\\mssqllocaldb;Database=EfInterceptorsDemo;Trusted_Connection=True;";

    options.UseSqlServer(connectionString);

    // Resolve all registered IInterceptor implementations
    var interceptors = serviceProvider.GetServices<IInterceptor>().ToArray();
    if (interceptors.Any())
    {
        options.AddInterceptors(interceptors);
    }

    // Helpful for debugging — optional in production
    options.EnableSensitiveDataLogging();
    options.LogTo(Console.WriteLine, LogLevel.Information);
});

builder.Services.AddControllers();
var app = builder.Build();

app.MapControllers();
app.Run();

9. UsersController (controller + simple business logic)

using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly AppDbContext _db;

    public UsersController(AppDbContext db) => _db = db;

    [HttpGet]
    public async Task<IActionResult> GetUsers()
    {
        var users = await _db.Users.ToListAsync(); // triggers ReaderExecuting / ReaderExecuted
        return Ok(users);
    }

    [HttpPost]
    public async Task<IActionResult> AddUser([FromQuery] string name)
    {
        if (string.IsNullOrWhiteSpace(name)) return BadRequest("Name required");
        _db.Users.Add(new User { Name = name });
        await _db.SaveChangesAsync(); // triggers SaveChangesInterceptor + NonQueryExecuting/NonQueryExecuted
        return Ok();
    }

    [HttpDelete("dangerous")]
    public IActionResult AttemptDangerousDelete()
    {
        // This intentionally sends 'DELETE FROM Users' without WHERE to trigger the security interceptor
        _db.Database.ExecuteSqlRaw("DELETE FROM Users");
        return Ok("Attempted dangerous delete");
    }
}

10. How to test (step-by-step)

i. Run the app (F5 or dotnet run). Watch console.

ii. Create DB / Apply migrations (or ensure DB exists). Example quick seed:

Use EF migrations or ensure Users table exists. For quick test you can create with SQL Server LocalDB or dotnet ef migrations add Init && dotnet ef database update.

iii. Test Logging + Performance

GET http://localhost:5000/api/users
Expected console output (example):

[SQL LOG] ReaderExecuting: SELECT [u].[Id], [u].[Name] FROM [Users] AS [u]
[PERF] Query took 12 ms. SQL: SELECT [u].[Id], [u].[Name] FROM [Users] AS [u]

iv. Test Audit

POST http://localhost:5000/api/users?name=Alice

Expected console:

[AUDIT] User 'anonymous' is calling SaveChanges at 2025-09-01T...
[SQL LOG] NonQueryExecuting: INSERT INTO ...
[PERF] NonQuery took 15 ms. SQL: INSERT INTO ...

v. Test Security (blocked DELETE)

DELETE http://localhost:5000/api/users/dangerous

Expected API response: 500 Internal Server Error

Console:

[SECURITY] Blocked dangerous DELETE without WHERE.

The exception thrown by the interceptor will be visible in logs and will prevent row deletion.

11. Best Practices

Keep interceptors lightweight (avoid long-running logic).
Use structured logging (Serilog, Seq, Application Insights) instead of Console.WriteLine.
Separate concerns into multiple interceptors (logging, auditing, security).
Test performance impact before deploying to production.

12. Conclusion

Database Interceptors in Entity Framework Core (EF Core) are an underused but powerful feature that can transform how you interact with your database layer. They allow you to observe, manipulate, and enhance database operations seamlessly — all without altering your application logic directly.

Here’s why interceptors are so valuable:

Log SQL Queries

Capture every executed SQL statement.
Helps with debugging, troubleshooting, and understanding query patterns.
Ensures visibility into how EF Core translates LINQ into SQL.

Monitor Performance

Measure query execution time in real-time.
Detect slow or inefficient queries.
Optimize database performance with minimal overhead.

Block Risky Commands

Intercept and prevent accidental destructive operations like TRUNCATE or DROP.
Enforce business rules and security policies at the database level.
Reduce risks of data corruption or loss.

Add Auditing

Track user activity, including inserts, updates, and deletes.
Automatically store metadata such as timestamps, user IDs, and IP addresses.
Ensure compliance with auditing and regulatory requirements.

In short, database interceptors elevate you from beginner-level logging to hero-level auditing, monitoring, and security. They give developers deep insight, precise control, and safer interactions with the database — all while keeping the application code clean and maintainable.

13. Code Download

The code developed during this article can be found here.

Mastering Hangfire in .NET 9: A Complete Guide to Background Jobs

Madusanka Bandara — Sun, 31 Aug 2025 15:11:10 +0000

1. Introduction

In modern web applications, not all tasks should run during the main user request. Some processes—like sending emails, generating reports, cleaning up logs, or syncing data—can take seconds or even minutes to complete. Running these tasks inline would slow down the application and create a poor user experience. This is where background jobs come into play.

A background job is any task that runs outside of the main request/response cycle. Instead of making users wait for time-consuming operations, the application delegates these tasks to run in the background. This improves performance, keeps the application responsive, and allows developers to handle recurring or long-running work reliably.

For example:

Sending a confirmation email after user registration.
Generating invoices or reports at scheduled intervals.
Processing uploaded files (e.g., resizing images, parsing CSVs).
Performing database cleanups or backups.

With the release of .NET 9, Microsoft continues to provide strong support for background processing. Developers can use built-in approaches like IHostedService or BackgroundService for simple scenarios. However, for more advanced requirements—such as retries, job persistence, and monitoring—frameworks like Hangfire offer a much more robust solution.

In this article, we’ll explore how to leverage Hangfire in .NET 9 to implement reliable, scalable, and maintainable background jobs.

2. What is Hangfire?

Hangfire is an open-source framework for managing background jobs in .NET applications. It allows developers to run fire-and-forget, delayed, recurring, or continuation jobs without writing complex infrastructure code. Hangfire handles job execution, persistence, retries, and monitoring out of the box, making it one of the most popular choices for background processing in the .NET ecosystem.

At its core, Hangfire uses a persistent storage (SQL Server, PostgreSQL, Redis, etc.) to queue and track jobs. This ensures that even if your application restarts or crashes, pending jobs will still be processed reliably.

Here’s why Hangfire often makes a better choice:

Persistence: Jobs survive application restarts and crashes.
Retries & Error Handling: Built-in retry logic prevents job loss.
Monitoring: The Dashboard provides visibility into job execution.
Scalability: Can run multiple servers to process jobs concurrently.
Flexibility: Supports different storage providers (SQL, Redis, etc.).

3. Setting Up Hangfire in .NET 9

Now that we understand what Hangfire is and why it’s powerful, let’s walk through the setup in a .NET 9 Web API or MVC project. Currently I'm choosing to web api project to implement Hangfire background job.

3.1 Installing Required NuGet Packages

Add the below NuGet packages to the project.

Hangfire.AspNetCore
Hangfire.SqlServer

Hangfire.AspNetCore → Integrates Hangfire with ASP.NET Core apps
Hangfire.SqlServer → Enables SQL Server as persistent storage for jobs

If you’re using a different storage provider (e.g., PostgreSQL, Redis), install the respective package.

3.2 Configuring Hangfire in Program.cs

In .NET 9, most configurations go inside Program.cs.

using Hangfire;

var builder = WebApplication.CreateBuilder(args);

// 1. Add Hangfire services and configure SQL Server storage
builder.Services.AddHangfire(config =>
    config.UseSqlServerStorage(builder.Configuration.GetConnectionString("HangfireConnection")));

// 2. Add Hangfire background processing server
builder.Services.AddHangfireServer();

var app = builder.Build();

// 3. Enable Hangfire Dashboard
app.UseHangfireDashboard("/hangfire");

// Example: register a sample job
app.MapGet("/", (IBackgroundJobClient backgroundJobs) =>
{
    backgroundJobs.Enqueue(() => Console.WriteLine("Hello from Hangfire!"));
    return "Background job has been queued.";
});

app.Run();

3.3 Connecting with SQL Server for Storage

In your appsettings.json, define the Hangfire connection string:

{
  "ConnectionStrings": {
    "HangfireConnection": "Server=localhost;Database=HangfireDB;User Id=sa;Password=YourPassword;TrustServerCertificate=True;"
  }
}

4. Types of Background Jobs in Hangfire

One of Hangfire’s biggest strengths is the variety of job types it supports. Depending on your scenario, you can run jobs immediately, after a delay, on a schedule, or chained together. Let’s go through each type with examples.

4.1 Fire-and-Forget Jobs

These are executed immediately and only once. They are useful for tasks that don’t need to block the main user request.


using Hangfire;

public class EmailService
{
    public void SendWelcomeEmail(string email)
    {
        Console.WriteLine($"Welcome email sent to {email}");
    }
}

// Usage
BackgroundJob.Enqueue<EmailService>(service => service.SendWelcomeEmail("user@example.com"));

4.2 Delayed Jobs

These jobs are scheduled to run after a specified delay.

BackgroundJob.Schedule(() => Console.WriteLine("This job runs after 2 minutes"), 
                       TimeSpan.FromMinutes(2));

4.3 Recurring Jobs (with Cron)

Recurring jobs run on a schedule, similar to CRON jobs in Linux.

RecurringJob.AddOrUpdate("daily-report", 
    () => Console.WriteLine("Generating daily report..."), 
    Cron.Daily);

Other Cron expressions provided by Hangfire:

Cron.Minutely → every minute
Cron.Hourly → every hour
Cron.Daily → once a day
Cron.Weekly → once a week
Cron.Monthly → once a month

4.4 Continuation Jobs

These jobs run only after a parent job has finished.

var parentJobId = BackgroundJob.Enqueue(() => Console.WriteLine("Step 1: First job executed"));

BackgroundJob.ContinueJobWith(parentJobId, 
    () => Console.WriteLine("Step 2: Continuation job executed"));

5. Exploring the Hangfire Dashboard

One of Hangfire’s most powerful features is its interactive dashboard. It provides real-time visibility into background jobs, queues, and processing servers. With just a browser, you can monitor the health of y

5.1 Navigating the UI

Once enabled in your app:

app.UseHangfireDashboard("/hangfire");

You can open http://localhost:5000/hangfire in the browser.

The dashboard is divided into several sections:

Jobs → View jobs by state (Succeeded, Failed, Scheduled, Processing, Deleted).
Recurring Jobs → See all scheduled recurring tasks with their CRON expressions.
*Queues *→ Monitor job queues and check how many workers are processing them.
Servers → Displays active Hangfire servers running your jobs.
Retries → Track jobs that have failed and are waiting for a retry.

5.2 Monitoring Running & Completed Jobs

From the Jobs tab, you can:

Check which jobs are currently running.
See detailed logs for completed jobs.
Inspect job parameters and execution history.

5.3 Retrying Failed Jobs

If a job fails (due to a network error, database timeout, etc.), Hangfire automatically retries it a few times based on the retry policy.

You can manually retry a failed job from the dashboard.
Failed jobs are highlighted with detailed exception logs.
This makes Hangfire extremely reliable for critical tasks like sending invoices or payments.

5.4 Securing the Dashboard with Authentication

By default, the dashboard is open to anyone who knows the URL. This is fine for local development but must be secured in production.

You can add authentication using DashboardOptions:

using Hangfire.Dashboard;

app.UseHangfireDashboard("/hangfire", new DashboardOptions
{
    Authorization = new[] { new MyDashboardAuthorizationFilter() }
});

public class MyDashboardAuthorizationFilter : IDashboardAuthorizationFilter
{
    public bool Authorize(DashboardContext context)
    {
        // Example: allow only authenticated users
        var httpContext = context.GetHttpContext();
        return httpContext.User.Identity?.IsAuthenticated ?? false;
    }
}

6. Advanced Usage Patterns

Once you’re comfortable with basic Hangfire jobs, you can unlock its advanced features to build more scalable and maintainable systems. Let’s explore some common patterns.

6.1 Using Dependency Injection in Hangfire Jobs

Hangfire integrates with ASP.NET Core’s built-in Dependency Injection (DI) container. This allows you to inject services directly into your job methods instead of writing static helpers.

public interface IEmailService
{
    void SendWelcomeEmail(string email);
}

public class EmailService : IEmailService
{
    public void SendWelcomeEmail(string email)
    {
        Console.WriteLine($"Email sent to {email}");
    }
}

// Register service in Program.cs
builder.Services.AddScoped<IEmailService, EmailService>();

// Enqueue job with DI
BackgroundJob.Enqueue<IEmailService>(service => service.SendWelcomeEmail("user@example.com"));

6.2 Creating a Custom Job Scheduler with Cron

For advanced scheduling, you can define custom CRON expressions.

Example: Run a cleanup job every Monday at midnight.

RecurringJob.AddOrUpdate("weekly-cleanup",
    () => Console.WriteLine("Performing weekly cleanup..."),
    "0 0 * * 1"); // Cron format: minute hour day month weekday

6.3 Handling Concurrency & Queue Management

By default, all jobs run in the default queue. For more control, you can assign jobs to custom queues and configure workers accordingly.

// Enqueue job into a custom "emails" queue
BackgroundJob.Enqueue(() => Console.WriteLine("Email Job"), new EnqueuedState("emails"));

In Program.cs, configure Hangfire Server to listen to multiple queues:

builder.Services.AddHangfireServer(options =>
{
    options.Queues = new[] { "default", "emails", "reports" };
});

6.4 Scaling Hangfire with Multiple Servers

Hangfire is designed for horizontal scaling. You can run multiple instances of your application (on different servers or containers), and they will all share the same job storage (e.g., SQL Server or Redis).

Each server pulls jobs from the shared storage.
Jobs are distributed across workers automatically.
Failed jobs are retried by any available server.

This makes Hangfire suitable for high-traffic, production workloads.

builder.Services.AddHangfireServer(options =>
{
    options.WorkerCount = Environment.ProcessorCount * 5; // Scale with CPU cores
});

7. Best Practices for Production

Running Hangfire in production requires careful planning to ensure reliability, security, and performance. Below are some best practices you should follow:

7.1. Logging & Monitoring Background Jobs

Integrate structured logging (e.g., with Serilog or NLog) to track job execution.
Use Hangfire’s built-in job history tracking for insights.
Consider external monitoring tools like Application Insights, ELK stack, or Prometheus/Grafana for deeper visibility.

public class EmailService
{
    private readonly ILogger<EmailService> _logger;

    public EmailService(ILogger<EmailService> logger)
    {
        _logger = logger;
    }

    public void SendWelcomeEmail(string userEmail)
    {
        _logger.LogInformation("Sending welcome email to {User}", userEmail);
        // email sending logic
    }
}

7.2 Retry Policies & Error Handling

Hangfire automatically retries failed jobs (default: 10 attempts).
Configure retry policies based on job criticality.
Use [AutomaticRetry(Attempts = 3, OnAttemptsExceeded = AttemptsExceededAction.Fail)] to fine-tune.

public class ReportGenerator
{
    [AutomaticRetry(Attempts = 3, OnAttemptsExceeded = AttemptsExceededAction.Fail)]
    public void GenerateDailyReport()
    {
        // Report generation logic
    }
}

7.3. Securing Hangfire Dashboard in Production

app.UseHangfireDashboard("/hangfire", new DashboardOptions
{
    Authorization = new[] { new HangfireCustomAuthorizationFilter() }
});

Custom filter:

public class HangfireCustomAuthorizationFilter : IDashboardAuthorizationFilter
{
    public bool Authorize(DashboardContext context)
    {
        var httpContext = context.GetHttpContext();
        return httpContext.User.Identity?.IsAuthenticated == true &&
               httpContext.User.IsInRole("Admin");
    }
}

7.4. Database Performance Considerations

Hangfire stores jobs in SQL Server; optimize DB for high insert/update throughput.
Use separate DB schema or instance if you have high job volume.
Clean up old job history with Hangfire’s built-in housekeeping jobs.

app.UseHangfireServer(new BackgroundJobServerOptions
{
    Queues = new[] { "default" },
    WorkerCount = Environment.ProcessorCount * 5 // Tune based on load
});

8. Conclusion

Background job processing is a critical part of building modern, scalable applications, and Hangfire makes it both simple and powerful in the .NET 9 ecosystem. With its persistence, retry mechanisms, flexible job types, and intuitive dashboard, Hangfire provides a production-ready framework for handling tasks that don’t belong in the main request pipeline.

While BackgroundService may be sufficient for lightweight or one-off background tasks, Hangfire shines when you need reliability, visibility, and scalability. By following best practices—such as securing the dashboard, tuning retry policies, and monitoring system performance—you can ensure your background jobs run smoothly in production environments.

As .NET 9 continues to improve performance and developer experience, pairing it with Hangfire allows you to build robust, fault-tolerant, and scalable background processing systems that enhance both your application’s performance and your users’ experience.

Real-Time Email Notifications in .NET Using Microsoft Graph API

Madusanka Bandara — Wed, 20 Aug 2025 08:09:56 +0000

Monitoring emails in real-time is a common requirement for businesses. With Microsoft Graph API, you can automatically log email details, download attachments, and maintain daily logs. In this article, we’ll create a .NET Web API to handle email notifications.

1. Introduction

Microsoft Graph API provides access to Office 365 services like emails, calendars, and users.

With this setup, we can:

Subscribe to a user’s inbox
Receive webhook notifications for new emails
Log email details to a file in JSON format
Download attachments automatically

This is useful for automated email monitoring and reporting.

2. Prerequisites

Before starting, ensure you have:

.NET 6/7/8 project
Visual Studio or VS Code
Office 365 account

NuGet packages:

Microsoft.Graph  
Azure.Identity
Newtonsoft.Json

3. Setting Up Microsoft Graph API

3.1 Register an Application in Azure

i. Go to Azure Portal (https://portal.azure.com/) → App Registrations → New Registration

ii. Provide a name (GraphNotificationDemo), Supported account types (Accounts in any organizational directory and personal Microsoft accounts) and redirect URI (https://localhost)

Click Register.

iii. Note down the Application (client) ID and Directory (tenant) ID for later use.

iv. Add a client secret (Manage → Certificates & secrets → New client secret → Enter a "Description", and select the "Expires" duration.

Click Add.

v. Note down the client secret value for future reference.

vi. API Permissions (Manage → API Permissions → Add a permission → Microsoft Graph)

vii. Add API permissions:

Mail.Read
Mail.ReadWrite
Mail.ReadBasic

4. Ngrok

Ngrok allows calls from the internet to be directed to your application running locally without needing to create firewall rules.

Install Ngrok from https://ngrok.com/

On the command prompt, Run below command:

ngrok http 5000

5. Create an ASP.NET Core web API project

i. Open Visual Studio 2022 and create a new project. From the available templates, select ASP.NET Core Web API.

ii. Give your project a specific name and choose the location where you want to save it. After that, click the Next button.

iii. In the next step, select the framework as .NET 8 (LTS), since it is the latest long-term support version. Finally, click Create to generate your new Web API project.

iv. Add the below NuGet packages to the project.

Azure.Identity
Microsoft.Graph
Newtonsoft.Json

v. Create a configuration class:

public class MyConfig
{
    public string AppId { get; set; }
    public string TenantId { get; set; }
    public string AppSecret { get; set; }
    public string Ngrok { get; set; }
}

vi. Add your credentials in appsettings.json.

"MyConfig": {
  "AppId": <<--YOUR CLIENT ID-->>,
  "AppSecret": <<--YOUR CLIENT Secret-->>,
  "TenantId": <<--YOUR Tenant Id-->>,
  "Ngrok": <<--YOUR Ngrok URL-->>
}

vii. Update Program.cs file:

using changenotifications.Models;

var config = new MyConfig();
builder.Configuration.Bind("MyConfig", config);
builder.Services.AddSingleton(config);

//app.UseHttpsRedirection(); -- comment out the following line to disable SSL redirection.

viii. Subscribing to a User Inbox:

What is a subscription?

A subscription tells Graph API to send POST requests to your server whenever a new email arrives. Subscriptions expire, so we’ll set up auto-renew.

var subscription = new Subscription
{
    ChangeType = "created",
    NotificationUrl = $"{config.Ngrok}/api/notifications",
    Resource = $"/users/{userId}/mailFolders('Inbox')/messages",
    ExpirationDateTime = DateTime.UtcNow.AddMinutes(5),
    ClientState = "SecretClientState"
};

var newSubscription = await graphClient.Subscriptions.PostAsync(subscription);

ix. Webhook Endpoint

Create a [HttpPost] endpoint to receive notifications:

[HttpPost]
public async Task<ActionResult> Post([FromQuery] string validationToken)
{
    if (!string.IsNullOrEmpty(validationToken))
    return Ok(validationToken); // Graph validation
}

x. Parsing Notifications

After receiving a POST, extract userId and messageId to fetch the full email:

var message = await graphClient.Users[userId].Messages[messageId].GetAsync();

xi. Logging Email Details

We log key email details such as the subject, sender, recipients (To & CC), received and sent dates, body preview, and attachments.

var logFile = Path.Combine(BaseDir, "logs", $"EmailLog_{DateTime.UtcNow:yyyyMMdd}.txt");
await File.AppendAllTextAsync(logFile, JsonSerializer.Serialize(logEntry, new JsonSerializerOptions { WriteIndented = true }));

xii. Downloading Attachments

If the email has attachments, save them in a folder:

if (attachment is FileAttachment fileAtt)
{
    var savePath = Path.Combine(msgFolder, fileAtt.Name);
    await File.WriteAllBytesAsync(savePath, fileAtt.ContentBytes);
}

Folder structure:

C:\EmailAttachments\20250819\<MessageId>\

xiii. Auto-Renew Subscriptions

Subscriptions expire. Use a Timer to renew:

if (subscription.ExpirationDateTime < DateTime.UtcNow.AddMinutes(2))
RenewSubscription(subscription);

6. Test the application

i. Open Swagger in the browser, trigger the subscribe-inbox GET endpoint from the Notifications controller, and you will receive a response like below.

After subscribing, the system sends an email to the user, logs all email details, and saves any email attachments in the file path C:\EmailAttachments.

7. Summary

In this article, we learned how to use Microsoft Graph API with .NET to read emails, create inbox subscriptions, handle real-time notifications, log email details into daily text files, and download attachments. We also covered how to set up auto-renewal for subscriptions to keep the system running continuously. With this setup, you can build a reliable email monitoring and processing system for business or personal applications.

8. Code Download

The code developed during this article can be found here.

DEV Community: Madusanka Bandara

Mastering Database Interceptors in .NET Core Web API (Beginner to Hero)

1. Introduction

2. Prerequisites

3. Beginner Level: Setting Up a Web API with EF Core

4. Creating a Simple Logging Interceptor

5. Intermediate Level: Measuring Performance

6. Advanced Level: Blocking Dangerous SQL

7. Hero Level: Auditing User Actions

8. Registering the Interceptor in Program.cs

9. UsersController (controller + simple business logic)

10. How to test (step-by-step)

11. Best Practices

12. Conclusion

13. Code Download

Mastering Hangfire in .NET 9: A Complete Guide to Background Jobs

1. Introduction

2. What is Hangfire?

3. Setting Up Hangfire in .NET 9

4. Types of Background Jobs in Hangfire

5. Exploring the Hangfire Dashboard

6. Advanced Usage Patterns

7. Best Practices for Production

8. Conclusion

Real-Time Email Notifications in .NET Using Microsoft Graph API

1. Introduction

2. Prerequisites

3. Setting Up Microsoft Graph API

4. Ngrok

5. Create an ASP.NET Core web API project

6. Test the application

7. Summary

8. Code Download

8. Registering the Interceptor in `Program.cs`