Best practices for integrating the Fabric ML Model endpoint with an application (preferably .NET)?

Hi vkeda29​ 

For auth, check the docs. It might vary depending on the endpoint that you want to use, but in general the ML endpoints do support managed identities, service principals, and users. Endpoint - REST API (MLModel) | Microsoft Learn

For permissions, also check the API docs, they specify which permissions are required. 
The Activate ML Model endpoint (Endpoint - Activate ML Model Endpoint Version - REST API (MLModel) | Microsoft Learn) specifies that the caller must have write on the model. 

Looking at the permissions table here: 
Data science roles and permissions - Microsoft Fabric | Microsoft Learn

That means that if access is granted through workspace roles, the caller needs to have a role of at least contributor. 

For API integration, this varies depending on the specific endpoints you are using. THe docs have example calls for all endpoints, so that is a good place to start. 

For async calls, yes you will need to ensure that your .net application is built to handle async calls well, as the endpoints will take some time to return depending on which endpoint you are using. 

To test different versions, the activate endpoint call does specific an endpoint name or version, however I would recommend you test out new model versions in a different workspace in a DEV/TST version of your application, and not rely on Fabric keeping all versions available in your production environment. 

Hi vkeda29​,

I'll focus on the .NET side, since that's where most of the integration effort goes. Treat the endpoint like any other Entra-protected Fabric API: get a token for the Fabric resource, call the scoring URL shown in the model's endpoint pane, and send the payload in the format of the sample request shown there.

For the backend, use Azure.Identity so the same code works with a service principal locally/CI and a managed identity in Azure. The SPN needs the tenant setting that allows service principals to use Fabric APIs, plus access to the workspace that holds the model. Give it the least role that works in your test, and check the current docs since the endpoint feature is still evolving.

// Program.cs
builder.Services.AddSingleton<TokenCredential>(new DefaultAzureCredential()); // MI in Azure, SPN via env vars elsewhere
builder.Services.AddTransient<FabricAuthHandler>();
builder.Services.AddHttpClient<ScoringClient>(c =>
{
    c.BaseAddress = new Uri(builder.Configuration["Fabric:ScoringUrl"]!);
    c.Timeout = TimeSpan.FromSeconds(30);
})
.AddHttpMessageHandler<FabricAuthHandler>()
.AddStandardResilienceHandler(); // retries 429/5xx with backoff (Microsoft.Extensions.Http.Resilience)

// FabricAuthHandler.cs - token is cached and refreshed by Azure.Identity
public class FabricAuthHandler(TokenCredential cred) : DelegatingHandler
{
    static readonly string[] Scope = ["https://api.fabric.microsoft.com/.default"];
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage req, CancellationToken ct)
    {
        var token = await cred.GetTokenAsync(new TokenRequestContext(Scope), ct);
        req.Headers.Authorization = new AuthenticationHeaderValue("Bearer", token.Token);
        return await base.SendAsync(req, ct);
    }
}

For versioning, don't hardcode the version-specific URL in the app. Keep the scoring URL in configuration (App Configuration or Key Vault). Then switching versions is: activate the new version's endpoint, smoke-test it, flip the config value, and deactivate the old one after a soak period. If your endpoint pane offers a default-version URL, point the app at that instead and switch the default in Fabric.

Also keep the endpoint call off the request path where you can. Real-time endpoints can scale down when idle, so the first call after a quiet period can be slow. A small warm-up ping on startup, plus a sensible timeout and fallback in the app, avoids user-facing hangs.

So my overall approach would be:

Auth -> DefaultAzureCredential (MI in Azure, SPN elsewhere), scope = Fabric API
SPN -> tenant setting for Fabric APIs + least workspace role that works
HttpClient -> auth handler + resilience handler (429/5xx retry) + timeout
Scoring URL in config -> version switch = config flip, not redeploy
Warm-up + fallback for cold endpoints

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.

I think one thing missing here is that scoring itself needs MLModel Write permission, even after the endpoint is active. A valid Entra token alone isn't enough.

In .NET, 202 means the prediction isn't ready yet. Poll Location using Retry-After, then fetch the result. Handle 429 with Retry-After too. For model updates, keep the app on /endpoint/score. Test the new version through /versions/{name}/score, then change the default in Fabric. Both versions can stay active, up to five total. Just keep an eye on Fabric capacity usage.

Hi vkeda29​,

Thank you for reaching out to Microsoft Fabric Community.

Thank you tayloramy​, jubinsoni​ and Kagiyama_yutaka​ for the prompt response.

As we haven’t heard back from you, we wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa

Hi vkeda29​,

We wanted to kindly follow up to check if the solution provided by the user's for the issue worked? or let us know if you need any further assistance.

Thanks and regards,
Anjan Kumar Chippa

Hi vkeda29

Same token string working in Postman but failing in the app usually means the two calls are not the same identity. Postman is probably sending a token for your own user. The app is likely running as a service principal or managed identity, and Fabric checks those differently.

Decode both tokens at jwt.ms and compare them. The aud should be https://api.fabric.microsoft.com. A user token carries scp, an app token carries roles, and oid or appid shows who the caller really is.

If the app token is a service principal or managed identity, check two things. First, the tenant setting Service principals can use Fabric APIs must be on, and the identity must be in the allowed group if the setting is limited to one. Second, the identity needs write on the model, which in practice means Contributor or higher on the workspace.

I can't see your app, so I can't tell which of these it is. Does the app's token decode as a user or as an app?