Getting Started with Monaiq in Five Minutes

The Scenario

Let's say you've built a productivity tool. It's got a free tier — basic task management, simple dashboards — and a Pro tier with advanced analytics, custom PDF exports, and priority support. The code works. Users are signing up. Now you need to actually charge for the Pro features instead of giving everything away.

You need three things: a way to define what "Pro" means in terms of features, a way to check whether a user has Pro access at runtime, and a way to connect that to payment. We'll focus on the first two — defining your product and enforcing access. That's what you can ship in five minutes.

Setting Up Your Product

First, you need to tell Monaiq about your product and what features each tier includes. You can do this through the dashboard — it's a straightforward form — or you can use the MCP server directly from your IDE.

If you have the MCP server installed, you can just tell your AI assistant what you want. "Create a product called TaskFlow Pro with two access features: advanced-analytics and pdf-export." The assistant calls the MCP tool, the product is created, and you never left your editor.

Either way, you end up with a product that has named features. Each feature has a type: access (boolean — you have it or you don't), allowance (you get N uses per billing period), or rate-limit (throttled — N per time window). For our Pro tier, advanced-analytics and pdf-export are both access features.

Next, create an offering — this is the thing customers actually buy. An offering bundles specific features at a price point. Create a "Pro" offering at $29/month that includes both access features. Create a "Basic" offering at $0 that includes neither. Your product catalog is done.

Adding Enforcement to Your Code

Now the interesting part: making your application actually check whether a user has access. Install the Monaiq client SDK:

dotnet add package Sidub.Licensing.Client

Configure it in your startup:

builder.Services.Configure<LicensingServiceOptions>(
    builder.Configuration.GetSection(nameof(LicensingServiceOptions)));

builder.Services.AddSidubLicensing();

The LicensingServiceOptions object lives in your appsettings.json (keep the real credential in user secrets or your host's secret store, not in source control):

{
  "LicensingServiceOptions": {
    "EncodedCredential": "<encoded-credential>",
    "LicenseServiceUri": "https://api.monaiq.com/licensing",
    "ConsumptionServiceUri": "https://api.monaiq.com/consumption",
    "BillableResourceId": "<resource-guid>"
  }
}

Then, wherever you need to gate a Pro feature, inject the licensing client and assert access:

public class AnalyticsController : ControllerBase
{
    private readonly ILicensingService _licensingService;

    public AnalyticsController(ILicensingService licensingService)
        => _licensingService = licensingService;

    [HttpGet("analytics/dashboard")]
    public async Task<IActionResult> GetDashboard()
    {
        var isAllowed = await _licensingService.AssertLicense(
            LicensingServiceReference.ServiceReference,
            licensingContext,
            ServiceAccessLicenseAssertion.Create("advanced-analytics"));

        if (!isAllowed)
            return Forbid();

        // User has Pro access — build the dashboard
        return Ok(await BuildAdvancedDashboard());
    }
}

That AssertLicense call does the heavy lifting. It checks the current user's license against your product definition and returns a boolean. If the user has access, you proceed normally. If they don't, you return a clean 403 response. No exceptions to catch — just a straightforward true or false.

What Happens at Runtime

Let's trace through what actually happens when a user hits the analytics endpoint.

User with Pro license: The SDK fetches a signed authorization for the configured license code, verifies its signature, confirms it carries the "advanced-analytics" feature, and returns. The assertion passes. Your analytics dashboard loads. The user never knows a license check happened.

User without Pro license: Same flow, but the entitlement check returns false. Your controller returns a 403 with a message like "This feature requires a Pro subscription." Clean, clear, no ambiguity.

What about latency? The SDK caches the verified authorization until it expires — seven days by default. The first check makes a network call; later checks are answered locally.

What about offline? If the Monaiq API is unreachable when the authorization needs refreshing, the SDK keeps serving the last verified one for a configurable grace period (AuthorizationStaleGraceMinutes, 60 by default). Your application doesn't stop working because of a transient network issue. When connectivity returns, the cache refreshes automatically.

Going Further

We've covered the basics: define a product, create an offering, enforce access in code. But there's a lot more you can do.

Allowances let you sell so many uses per billing period — API calls, generated reports, exports. Define an allowance feature, and Monaiq counts uses across every runtime of the seat while the SDK reserves ahead so a use never waits. The state view tells you how much is used, reserved and left, so you can warn a customer who is close. When they run out, the assertion throws AllowanceExhaustedException with the date the period resets, and the refused use is never counted.

Rate limiting is similar but time-windowed. "100 API calls per minute" is a rate-limit feature. The SDK tracks the window and enforces the boundary.

In-app purchase lets the application you ship sell your offerings itself. The buyer signs in with their own Monaiq identity and pays on Stripe Checkout, and the app receives their license code — no key of yours ships in the build.

The documentation covers all of these scenarios in detail. But for now — you have a product, an offering, and enforcement. You've gone from "it works" to "it earns" in about five minutes.