Mendix user subscriptions are the entitlements by which a customer licenses end-user access to apps built on the Mendix platform. Mendix describes its licences as following user-based pricing plans: customers pay according to how many users need access and what type of access they need.[1] The unit of count is not a device, a core or an app instance but an individual user, and the classification of that user (internal or external, one app or many) decides which pack the user consumes. This article follows the documented chain from the definitions in the Order Form to the monthly usage report.
Editions
Three user subscription categories are documented. A Multi-App Internal User is an internal user, meaning an employee or contractor of the customer or of an affiliated company or group, who can access any number of applications. Each such user is counted as one unique user regardless of how many apps the person accesses, and is licensed under the Multi-App Internal User Pack.[1] A Single-App Internal User is an internal user licensed for only one specific application and counted as one user limited to that designated app.[1] An External User is a user who is not an employee or contractor of the customer or its affiliates and who is explicitly marked External within the application data. External users count as one unique user across all apps designated for external use, under the External User Pack.[1]
The Order Form Definitions give the contractual wording. A Named User is an individual authorized by the customer to access its Applications with unique login credentials that identify one specific individual, and also any external system that accesses or is accessed by the Application.[5] An Internal User is a Named User who is an employee or contractor of the customer or an affiliated company within its group. An External User is a Named User who is not, and who is designated as an External User in the Mendix Platform.[5] The Control Center page names the corresponding licensing models Multi-App Internal User Subscription, Single-App Internal User Subscription and External User Subscription.[4] Pricing is volume-sensitive: the pricing FAQ states that the price per user falls as user volume grows and that external users, who access apps less often, are offered more attractive pricing, without publishing a schedule.[6]
Metrics
The metrics page rows for these units are Multi-App Internal User, Single-App Internal User, External User and Named User. Mendix does not charge for anonymous users accessing apps or for developers making apps on the platform.[6] A user who is no longer active does not count: only end users whose Mendix accounts are marked Active are counted toward the number of end users of the app.[1]
Older subscriptions use different metrics. The Order Form Definitions keep legacy definitions of Any App User (a Named or Anonymous User with access to apps on the platform under one account, counted per calendar day, where a login from several devices counts as one), Concurrent User (users who simultaneously access a specific app), Light User (a Named User who accesses apps on average once per week or less, measured quarterly) and a legacy External User who logs in no more than once a week for a maximum of thirty minutes. Mendix reserves the right to charge overage when Light Users exceed the number included, and legacy Internal Users could be converted to External Users at a ratio of 1:10.[5] The definitions page states that these legacy products are still used but are not available to new customers.[5]
Counting / floors
User metering is performed by the platform. It is enabled by default for apps deployed to Mendix Cloud and applies to Mendix Cloud and Mendix Cloud Dedicated environments.[2] Applications send user data back to the Mendix platform from all environments, but only data from the production environment is considered for subscription tracking. Usernames and other identifiers are hashed at source before transmission.[2] At the end of each month the platform aggregates the data, deduplicates users and rolls them up to the application portfolio level.[2]
Deduplication
Deduplication depends on a consistent identifier. Mendix states that a user who has different identifier values in the aggregated data cannot be recognized as the same user and is counted as multiple users.[2] The implementation guide describes a dedicated attribute, UserCommons.namedUserIdentifier.value, as the intended primary identifier, falling back to system.user.name, and recommends storing the user’s email address in lowercase. It also states that user metering currently reads values from system.user.name only, and that Mendix is working on giving the dedicated attribute priority when populated.[3] The guide warns that identity providers which issue pairwise identifiers per application, such as the sub claim from Microsoft Entra ID, can lead to the same person being counted several times if used as the identifier.[3]
Classification order
The platform evaluates users in a fixed sequence. First it identifies the user. Then, if the customer holds a valid External User Subscription and the user is explicitly marked External in the app, the user is classified as external and excluded from further steps. All remaining users are internal.[2] If the app is associated with a Single-App Internal User Subscription, its internal users are counted against that pack. All other internal users are classified as Multi-App Internal users, which is the default bucket.[2] An internal user who accesses several apps, one of which is covered by a Single-App subscription, is counted as a single-app user for that app and counted separately for every other app the person uses.[2]
Who classifies
The customer classifies. Mendix states that the customer is responsible for classifying users as Internal or External, and that classification by the platform using email domains or any other logic is not supported.[2][3] The guide lists three methods: IdP-based classification through the OIDC SSO, SCIM or SAML modules; user-role-based classification with the User Classification module, which Mendix recommends; and custom classification with the module or fully custom microflows.[3] The financial consequence of mistakes is stated directly: external users must be explicitly marked, they are otherwise counted as Internal, and the customer may then exceed its internal subscription capacity and be required to acquire additional internal user subscriptions.[3]
Ambiguity
Where classification is ambiguous Mendix treats the user as internal. The two examples given are a multi-app user marked Internal in one application and External in another, and a user holding both an Internal and an External user role under user-role-based classification.[2][3]
Deactivation
A user is counted if the account was active on any day of the calendar month. Actual logins, login frequency and the last-login timestamp are not relevant for metering.[3] Customers that want to reduce counts therefore need to deactivate or remove user records, for example through the SCIM or LDAP modules or their own provisioning logic, and should consider that removing records may delete associated data.[3] The SAML and OIDC SSO modules can recreate deleted users on login.[3]
Virtualization & partitioning
Not applicable to user subscriptions. Mendix publishes no rule that links user counts to the number of virtual machines, containers or cloud nodes. A user is counted once across all of the customer’s apps in the same bucket, whichever environment type hosts them, subject to the Mendix Cloud scope of automatic metering noted above.[2]
Cloud / BYOL
Automatic end-user metering is documented for Mendix Cloud and Mendix Cloud Dedicated.[2] For apps deployed elsewhere, such as SAP BTP, Kubernetes or customer servers, the licensing page states that licensed apps have concurrent and named user limits that depend on the pricing plan, and that internal and external classification must be reported by implementing User Metering for each end user.[1] Mendix Cloud documentation repeats that the number of end users supported by a licensed app depends on the pricing plan.[7] The documents reviewed do not say how Mendix reconciles usage for deployments without automatic reporting.
Programs
Single-App Internal User subscriptions must be assigned. Customers holding them must assign each to an app environment deployed to production, using the Assign action on the Named Users list of the End-Users page.[4] The End-Users page shows entitlements active today with expiry dates, the named user count per app and production environment for the current month, and a Usage Report tab that shows entitlements and consumption per subscription type for a calendar month. The report is generated on the first day of each month for the previous month’s usage.[4] Mendix marks the feature as Private Beta.[4]
Over-usage and compliance
When entitlements are exceeded, apps continue to work with no consequences to end users. The documentation states that over-usage needs to be discussed with the customer’s Technical Account Manager, Specialized Account Executive or Partner Contact.[4] The documents reviewed do not state a price for additional users or a contractual remedy. That belongs to the Order Form and the governing agreement. The practical preparation steps follow from the sources: confirm that every app populates a consistent user identifier, confirm that external users are marked in each app, review which apps are assigned a single-app subscription, and compare the monthly usage report with the entitlement cards.
Out of scope
This article does not cover the cloud resource packs and Cloud Tokens that size environments, runtime licences for environments outside Mendix Cloud, or the Mendix ISV Program, which the pricing page states is priced on a royalty basis rather than by apps and users.[6] It also does not cover anonymous access design or the technical details of the User Classification module.