Forem: Anoush

Scaling API Access with Azure API Management: From Manual to Self-Service

Anoush — Sun, 04 Jan 2026 22:03:40 +0000

Introduction

Working on a healthcare application using .NET and Azure. The backend is .NET Core with SQL Server and Azure Functions on Azure Cloud. This application is a B2B product, where we need to expose our APIs to external clients and users who integrate with our services.

We came out first with a traditional approach where each client would get custom API endpoints and we generate a GUID id (API key) for each client/user. We store the ids in our database and based on API key we authorize and authenticate the clients. But as we scaled up hundreds/thousands of facilities and users, this became unmanageable. Also, it is not secure to have the main API endpoint accessible to public. We needed a better way.

This article describes how I architected our API access to be scalable, self-service and more secure. Basically, going from a manually configured API setup to an automated multi-tenant API gateway that serves thousands of users with zero manual configuration.

The Problem

Our application needed to serve hundreds or thousands of external users across multiple facilities. Each facility needed access to our APIs to exchange data. But here's the challenge: each client has access to different APIs and needed different parameters to push and pull their data.

For example:

Facility A needs facilityId=5001&locationId=1001
Facility B needs facilityId=5002&locationId=1002
Facility C needs facilityId=5003&locationId=1003$specificParams=Ture

The traditional approach would be to create separate API id called API Key in the database and endpoints would access their data based on their API Key. Or worse, require each facility to pass their own parameters and trust they're sending the right ones. Neither scales. The first creates endpoint sprawl. The second creates security issues.

We needed our users to sign up, set up their settings (set their facility, location and other parameters in UI) and choose their API endpoint that could serve everyone securely, with each user automatically getting their correct parameters without manual configuration.

Architecture and Setup

We built our solution using three Azure services: Azure API Management (APIM), Azure Functions, and Azure Table Storage.
APIM acts as our API gateway. It's the single entry point for all external users. Functions handle our business logic and subscription management. I used APIM to set up API policies. Table Storage holds each subscription's custom parameters.

Here's how I set it up. In APIM, I created one API endpoint. This single endpoint serves all facilities. When a user calls this endpoint with their subscription key, APIM does all the heavy lifting automatically through a policy.

I have a separate function that is fully dedicated to managing APIM subscriptions. I created two main APIs: one to manage subscription creation (POST /api/subscription/create) and one to retrieve subscription parameters (GET /api/subscription/{id}). The first one is called when users sign up. The second one is called by APIM's policy to get that user's parameters.

In Table Storage, we store a simple table called ApiSubscriptions with three columns: SubscriptionId (the primary key), SubscriptionKey, and Parameters. When a user signs up, I store their parameters here as a query string like facilityId=5001&locationId=1001.

The Flow

When a user calls our API, here's what happens automatically:
The facility sends a GET request to https://api.example.com/data/ids with their subscription key in the header: Ocp-Apim-Subscription-Key: abc123...
APIM receives the request and validates the subscription key. If it's invalid, the request is rejected immediately.

Once validated, APIM executes our policy. The policy does three things in sequence:

First, it calls Azure AD to get an OAuth token. This token is needed to call our backend Function App securely. APIM makes a POST request to https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token with client credentials. Azure AD returns a bearer token.

Second, APIM calls our Function App to get this subscription's parameters. It makes a GET request to /api/subscription/{subscriptionId} with the bearer token in the Authorization header. The Function App looks up the subscription in Table Storage and returns the parameters: facilityId=5001&locationId=1001.

Third, APIM appends these parameters to the main backend API call. It rewrites the URL from /data/ids to /data/ids?code={functionCode}&facilityId=5001&locationId=1001 and forwards the request to the Function App with the OAuth token.

The Function App processes the request with parameters and returns the facility's requested data. APIM forwards this response back to the user.
All of this happens in milliseconds. The facility doesn't know any of this is happening. They just send their subscription key (in the header of the call) and get their data back.

The diagram shows the complete flow from API Client through APIM to backend services with OAuth authentication and dynamic parameter injection.

The APIM Policy
The entire flow is controlled by an APIM policy. This is an XML-based configuration that runs for every API request. Here's what our policy looks like, broken down into the three main steps:
Step 1: Get OAuth Token

<send-request mode="new" response-variable-name="tokenResponse" timeout="10">
    <set-url>https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token</set-url>
    <set-method>POST</set-method>
    <set-header name="Content-Type">
        <value>application/x-www-form-urlencoded</value>
    </set-header>
    <set-body>grant_type=client_credentials&client_id={id}&client_secret={secret}&scope={id}/.default</set-body>
</send-request>

This calls Azure AD and gets back an access token. We store it in a variable called tokenResponse.

Step 2: Get Subscription Parameters

<send-request mode="new" response-variable-name="subscriptionResponse" timeout="10">
    <set-url>@($"https://{function-app}/api/subscription/{context.Subscription.Id}?code={code}")</set-url>
    <set-method>GET</set-method>
    <set-header name="Authorization">
        <value>@("Bearer " + accessToken)</value>
    </set-header>
</send-request>

This calls our Function App to get the parameters. Notice we're using context.Subscription.Id which is the unique subscription identifier in APIM. We send the OAuth token in the Authorization header.

Step 3: Call Backend with Parameters

<set-header name="Authorization">
    <value>@("Bearer " + accessToken)</value>
</set-header>

<rewrite-uri template="@{
    string parameters = context.Variables["parameters"];
    return $"/api/data?code={code}&{parameters}";
}" />

This appends the parameters to the backend call and sets the OAuth token in the Authorization header. The backend API receives the request with both authentication and the facility's specific parameters.

That's the entire policy. Three steps that run automatically for every request.

I also have other types of APIM Policies. For example, one that I use often is the rate-limit policy. That protects our APIs when there are a lot of calls during a short amount of time. This built-in policy will give "Too Many Requests" (HTTP 429) when that occurs.

Subscription Management

We built a Function App to handle subscription lifecycle. It has two main APIs:

Create Subscription (POST /api/subscription/create)

This function does four things:

Creates the user in APIM (if they don't exist)
Creates the subscription in APIM for the selected product
Stores the subscription parameters in Table Storage
Returns the subscription key and ID to the user

Here's the data flow: user submits their email, name, product selection, and facility selection through our signup portal. The Function App creates an APIM user using their email as the identifier. Then it creates a subscription for that user to our API product. Then it stores the subscription ID and parameters (facilityId=X&locationId=Y) in Table Storage. Finally, it returns the subscription key to the user.

*Get Subscription *(GET /api/subscription/{id})

This function is called by the APIM policy. It takes a subscription ID, looks it up in Table Storage, and returns the parameters. Simple lookup operation.

Both functions use OAuth authentication. Only APIM can call them because APIM uses Managed Identity to get a token from Azure AD.

One important configuration: the Function App's Managed Identity must authenticate to the correct Azure AD tenant. I explicitly set the tenant ID in the DefaultAzureCredential to ensure it gets tokens from the right Azure AD instance. Without this, authentication fails with a tenant mismatch error.

Developer Portal

I built two signup portals: one integrated into the APIM Developer Portal and one standalone static website hosted on Azure Storage.

In the APIM Developer Portal, I created a custom page called "Create Subscription". Users can access this page, fill out a form with their email, name, product selection, facility selection, other settings and click "Create Subscription". The form calls our Function App's create endpoint, and the user immediately gets their subscription key displayed on screen.

The standalone portal is a simple HTML page with JavaScript. It does the same thing but can be shared with external users who don't need to log into the APIM portal. We use this for quick onboarding by email invitations.

Both portals load the facility list dynamically from another Function App endpoint (GET /api/facilities) which queries our database for active facilities. It also lets users choose their APIM Product or API Group.
For the portals to call the Function App from the browser, I configured CORS in the APIM policy. I set allowed-origins to wildcard (*) for the POC. For production, this should be locked down to specific portal URLs only.

When the user submits the form, JavaScript calls POST /api/subscription/create with the payload example:

{
  "email": "user@example.com",
  "name": "John Doe",
  "product": "example-apis",
  "facilityId": "5001",
  "locationId": "1001"
}

The Function App does all the work and returns:

{
  "subscriptionKey": "abc123...",
  "subscriptionId": "user-example-com-xyz789"
}

The portal displays this to the user with instructions on how to use it.

Conclusion

This architecture solved our multi-tenant API access problem, without admin involvement and separates authentication and authorization using APIM. Each user gets their correct parameters automatically without manual configuration.

The key components:

APIM handles routing and policy execution
Azure Functions manage subscriptions and business logic
Table Storage holds subscription parameters
OAuth secures all communications
APIM Policy ties it all together with three simple steps

If you're building B2B APIs that need to serve multiple tenants with different parameters, this pattern works. It's scalable, secure, and self-service.

The full code and APIM policy are available in production. The system runs itself.

User Connectivity: Two Years in Production — Lessons Learned and New Patterns

Anoush — Wed, 24 Dec 2025 06:23:54 +0000

Introduction

This is a follow-up to my previous post on User Connectivity: A Real-time Web Solution for Online and Offline User Status. It has been almost two years since I first deployed my user connectivity solution to production. What started as an experiment has become a cornerstone of my architecture.
Could I make it simpler? Yes. However, the time and effort for an upgrade is not worth it given other priorities. The system has been rock solid, and I have expanded its use to solve other challenges in my application.

Expanding the Pattern: Solving Database Deadlocks

Recently, I encountered complex database deadlock issues caused by several API processes. After analyzing the problem, I recognized an opportunity to apply my event-driven architecture. By separating out specific tasks and processing them asynchronously, I eliminated the deadlocks entirely.
This led me to create a centralized service I call the Event Distributor. An Azure Function App responsible solely for listening to Redis expiration events and forwarding them to an Azure Event Grid queue. Multiple Azure Function App workers then process events from this queue.

Event Distributor Architecture

The goal of the Event Distributor is simple: one central service that listens to Redis expiration events and nothing else.

This separation provides several benefits:

Traceability: All events pass through a single point, making it easier to trace issues.
Logging: Every received event is logged to an Azure Cosmos DB with its status.
Scalability: Worker functions can scale independently based on queue depth.
Reliability: A single, well-monitored listener reduces the risk of missed events.

Key Observations: Azure Services

After two years of running this architecture, I have two critical observations for anyone implementing a similar solution with Azure services.

1. Use Premium Plan for Redis Listeners
If your Azure Function App uses the RedisPubSubTrigger to listen for Redis expiration events, you must use the Premium plan. The Consumption plan is not reliable for this use case.

Why? The Consumption plan has cold start delays and limited connection lifetimes. When the function app is idle, it can go to sleep and miss events from Redis. With the Premium plan, your function app is always on with long-lived connections — no cold starts, no missed events. I have not seen a single lost event since moving to Premium.

You may ask: how did the original user connectivity solution work on the Consumption plan?
The answer is traffic volume. Even in idle mode, my application generates 170–200 heartbeat events per second. During peak usage, this increases 6–10 times. The function app never goes to sleep because of this constant traffic. Additionally, my Heartbeat function app includes both the RedisPubSubTrigger and HTTP triggers, keeping it active.
For a dedicated Event Distributor that only listens to Redis expiration events, the Premium plan is essential.

2. Azure Managed Redis Limitation
Azure has introduced a new Redis service called Azure Managed Redis (formerly Redis Enterprise). This service runs on a clustered architecture with multiple Redis servers under the hood.

However, there is a significant limitation: these servers cannot be fully configured to send expiration events reliably. When the underlying servers restart or cycle, they lose their configuration and stop sending expiration events.

I have reported this issue to Microsoft. They confirmed it is on their backlog, but as of today, there is no solution. If your architecture depends on Redis key expiration events, be aware of this limitation before migrating to Azure Managed Redis.

Conclusion

My event-driven architecture has proven itself over two years of production use. It solved my original user connectivity requirements and has since helped me address complex database deadlock issues. The key takeaways:

Use the Premium plan for Redis listeners
Be cautious with Azure Managed Redis if you rely on expiration events

I hope this helps others take advantage of this architecture.

User Connectivity: A Real-time Web Solution for Online and Offline User Status

Anoush — Tue, 06 Feb 2024 06:46:08 +0000

Introduction:
This post explores user connectivity in a web application, focusing on displaying the real-time connectivity status of facilities. We'll discuss how users are associated with facilities, walk through our setup, communication methods with connected sessions, and our approach to ensuring a stable and reliable solution.

Connectivity Status:
In our context, connectivity status refers to whether a facility is online or offline. This status indicates whether one or multiple users associated with a facility are actively logged into our application.

Application Setup and Details:
Our application operates in real-time, using sessions associated with users. Users are linked to specific facilities, and each facility is associated with a distinct region or county.
The core of our real-time functionality involves notifying all relevant sessions/users about the facility's connectivity status in real-time, delivered to the user's browser using SignalR (Web Sockets protocol) event messages.
We host our application on Microsoft Azure Cloud, utilizing the following technology stack and

Azure Cloud Services:
Technology Stack:
Front-end: JavaScript/Angular
Back-end: .Net Core
Database: Azure SQL Server

Azure Services:
SignalR
Azure Event Hub
Redis Cache
Azure Functions

Solution:
Now, let's dive into the specifics of our solution.
To establish real-time user connectivity, our front-end application regularly sends heartbeat signals through simple Post API calls every 30 seconds. The heartbeat events are stored in an Azure Event Hub Queue, which can handle millions of events per second.

Heartbeat Event Process:
We utilize a worker service called the Heartbeat Monitor (implemented as Azure Functions) to read and store heartbeat events in Redis Cache. The events are stored in two lists: a Redis expiring list called Session list and another list called Session Value list, containing heartbeat event values.
Each time a heartbeat event is read, it is fetched from the Session list. If it does not exist, the session element is transactionally created in both lists to ensure synchronization. If the session already exists, the Session End Time is set to the expiration time in the Session Value list.

Expired Session Callback:
To manage session expiration, we listen to Redis expired keys and execute a function that processes the session and sets it to offline with a timestamp. This is done by configuring Redis to send events and listening to a specific event: __keyevent@0:expired.

However, Microsoft has introduced a new Azure Function Trigger, "RedisPubSubTrigger", which captures the expiration (__keyevent@0:expired) of a session more efficiently.

When a session expires, this listner function sets the session's offline timestamp in the session value list, which is set to null while session in online.

By listening to Redis expired keys, we execute function that process the session and set the session to be offline with timestamp. This was originally done by configuring the Redis to send events and listening to specific event "__keyevent@0:expired". However, Microsoft has new Azure Function Trigger "RedisPubSubTrigger" that capture the expire session. The session offline timestamp been set in the session value list, there after.

Session Monitor:
Another timer-based Azure Functions worker service runs every minute, processing each session in the Session Value list, associating sessions with facilities. After processing all sessions, the Session Monitor updates facility connectivity status, stores data in its private database, and removes offline sessions from the Session Value list.

Process Facility Session:
Moving from the Session Monitor's role, let's explore the 'Process Facility Session' step. Here, we update facility connectivity status and perform tasks for seamless user connectivity. The Session Monitor submits events to proper users or regions/counties, updates facility data in its database, and updates the facility status in the core database.

Conclusion:
The facility session process is highly efficient, processing only the updated facilities whose connectivity status has changed. It summarizes all sessions to the facility, avoiding the need to send events per session and reducing processing per browser connection.
Using Redis expiration keys is reliable and stable, streamlining functionality and code by eliminating the need to individually process each session in the list to determine its online or offline status.

Update (December 2024):
This architecture has been running successfully in production for over two years. I have published a follow-up article covering lessons learned, a new Event Distributor pattern, and important Azure service considerations: User Connectivity: Two Years in Production — Lessons Learned and New Patterns

Going Desktop to Mobile view by configuring the Angular router

Anoush — Tue, 09 Jul 2019 03:22:01 +0000

Working on an emergency application (with live data) using .net and angular. The backend is .net with SQL server and SignalR on Azure. This application is sales driven product, we came out first with desktop version and then mobile friendly version due to way the market and 90-80% of users are on desktop view.

This article describes how we architect our application do be responsive. Basically, going from an already existing desktop web application to responsive application. When referring to word “mobile” in article, it is not a mobile native application or Progressive Web App, it is referring to responsive application on different tables and mobile devices.

Architecture and Setup

We started by in our angular application under root folder “src”. We created a folder called “mobile”. We have the “app” folder for main desktop view, it can be renamed to “desktop”. This gave us a whole new place to have our mobile code and not been in the same folders with all other code, it is more organized, clean and separated from all other code.

In app router module “AppRoutingModule”, when application get loaded. We load an array of all paths of the application, from “app” and “mobile” folders. When application knows the size of window “window.innerWidth” it will modify the path array and rests the route configuration by calling "this.route.resetConfig()". Here we also listen to “window:resize” in the main component of the application for window resizing, and the router path gets modified and then router configuration gets reloaded. So, user can go from desktop to mobile view and vice and versa.

const desktopPreloadModules = [
  {
    path: 'dashboard', loadChildren: () =>
      import('app/modules/dashboard/dashboard.module')
        .then(mod => mod.DashboardModule)
  },
  {
    path: 'debug', loadChildren: () =>
      import('app/modules/debug/debug.module')
        .then(mod => mod.DebugModule)
  }
];

const mobilePreloadModules = [
  {
    path: 'dashboard', loadChildren: () =>
      import('mobile/modules/dashboard/dashboard.mobile.module')
        .then(mod => mod.DashboardMobileModule)
  },
  {
    path: 'debug', loadChildren: () =>
      import('mobile/modules/debug/debug.mobile.module')
        .then(mod => mod.DebugMobileModule)
  }
];

const appRoutes: Routes = [
  { path: 'login', component: LoginComponent },
  {
    path: 'main',
    component: MainComponent,
    canActivate: [AuthGuard],
    resolve: [AppDataResolver],
    children: [...desktopPreloadModules, ...mobilePreloadModules]
  },
  { path: '', redirectTo: '/main', pathMatch: 'full' },
  { path: '**', component: LoginComponent }
];

@NgModule({
  imports: [RouterModule.forRoot(appRoutes, { preloadingStrategy: SelectiveStrategy, enableTracing: false, scrollPositionRestoration: 'enabled' })],
  providers: [SelectiveStrategy],
  exports: [RouterModule]
})
export class AppRoutingModule {
  constructor(…) { … }
}

There is also CSS files that styling changes depending on the window size, we used media query for that, by calling:

@media only screen and (max-width: ####px)

In our application we also have some dynamic dialog boxes, we also override those components by reloading them either mobile view or desktop view.

After route is change the all components (that is in the current view) needs to be reloaded. Here, we solve this by simply navigating to and empty path this basically reloads all current component in the DOM (it is not refresh from server.)

Mobile Implementation

In the mobile for with similar path tree as desktop “app” folder, by using OOP inheritance, polymorphism and overriding methods. We could access all of the functionalities from desktop services and components and reused the code, by extending from same components. Following the open/closed principle. For example:

@Component({
  selector: 'my-mobile-component',
  templateUrl: './my.mobile.component.html'
})
export class MyMobileComponent extends MyDesktopComponent { }

In case mobile functionality is different than desktop, we override the desktop method in the mobile folder.

In our application which is medium to advanced application complexity. There is only one place that it is checking if application is mobile or desktop and that is in the “AppRoutingModule” there no “if (mobile) do this else do that” outside the router. We follow and stick with this pattern due to the fact that the application could be very messy. If we have a mobile specific component or function with extending the class from desktop and override or add mobile specific functions or view. Following the single responsibility principle.

Pros

Clean and organized code.
Easy to implement the mobile view application.
Reuse of the code, this saves us lots of time to impalement and test. The desktop code is already in production and been used by users, we know if works. So, we are confident that code works.
Follows the single responsibility principle
Follows the open/closed principle

Cons

If we want to override a desktop behavior or functionality we will need to extend it in mobile. This can give a little complexity to some deeper functionalities. However, doable by refactoring and using SOLID principles.
Can easily get a messy code if we breaking the pattern if someone writes “if (mobile) do this else do that” way or some other way.