1. Introduction to Automating MikroTik Hotspot User Provisioning
Every hotspot starts small. You add some local hotspot user entries on the router, hand out the credentials, and everything works. Then the venue gets busier, a sales desk starts selling access, or your small ISP signs up more subscribers, and the router’s user list turns into a chore that never ends. This guide shows you how to automate MikroTik hotspot user provisioning so the router stops being the place where accounts are created, edited, and deleted.
The idea is simple to state. Instead of maintaining accounts on each router, you let MikroTik Hotspot ask a central RADIUS server whether a login is allowed. That shift delivers the outcomes this article keeps coming back to: centralized credentials, per user policy delivery, and reliable accounting. Credentials live in a managed place outside the router. Each user’s limits travel with the login answer. Every session leaves a record you can use for operations and for deciding when to deactivate an account.
Here is the path we will follow. We start with why manual account handling breaks down, then move into centralized credential management with RADIUS and the conceptual setup that connects Hotspot to it. From there we cover provisioning users without local router entries, delivering policy through reply attributes, tracking sessions with accounting records, automating the account lifecycle from signup to removal, and a practical troubleshooting mindset. If you have been wondering how to automate MikroTik hotspot user provisioning without drowning in router edits, this is the whole picture in plain terms. Think of it as MikroTik hotspot automation built on concepts you already know from hotspot and RADIUS work.
2. Limitations of Manual User Creation in Hotspot
Anyone who has spent real time on hotspot user management knows the pattern. MikroTik hotspot manual user creation feels fast when the audience is small, and it quietly turns into your biggest source of repetitive work and avoidable mistakes as the audience grows. The problem is not that manual entry is wrong. The problem is that it ties every change to a person sitting in front of a router.
2.1 How Local Hotspot User Entries Are Stored
Local hotspot user entries live on the router itself. That means the router is the record keeper: each account, its password, and the policy attached to it are held there, and the only way to change them is to change them there. If your operation includes multiple routers, each router keeps its own separate set of entries, and nothing keeps those sets in step with each other.
This design is perfectly reasonable for a small, stable setup. It becomes awkward the moment your account list changes often, because the router was built to enforce access, not to act as a customer database.
2.2 Common Operational Issues With Manual Entry
Several problems show up when every change is made by hand.
Scaling is the obvious one. Each new customer means another entry to create, and each cancellation means another entry to find and remove. The workload grows with your user base, and it lands on whoever has router access.
Policy drifts next. Imagine you adjust what a particular access level allows. If entries were created at different moments, some carry the old policy and some carry the new one, and nobody notices until a customer complains that a friend with the same plan gets different treatment.
Update overhead follows. A renewal, a plan change, or a password reset all require someone to log in and edit. During busy periods those small jobs pile up.
Finally, error risk rises with every manual touch. A mistyped password, a wrongly chosen policy, or an expired account that someone forgot to remove can each create a support ticket or an access leak. None of these mistakes is dramatic on its own, but together they eat the time you wanted to spend on the network.
2.3 When Centralized Management Becomes Necessary
You do not need a formal threshold to know it is time. Watch for these signs: your user volume keeps growing, policy changes happen frequently, you need every user on the same plan to be treated the same way, and you need dependable records of who used the service and for how long. When you catch yourself keeping a spreadsheet just to remember which router entries need cleanup, you have already built a central record, only by hand and outside the system that enforces it.
That is the moment to let a central system own the accounts. The next section explains how.
3. Centralized Credential Management With RADIUS
Centralized credential management means the router no longer decides on its own whether a user may log in. A central service holds the accounts, and the router asks it. This is how you replace router by router manual handling with a single point of control, and it is the foundation for everything else in this guide. If you want a wider look at RADIUS authentication for hotspots in a billing context, that topic pairs well with what follows. Here we stay focused on the concept and on how to use RADIUS for MikroTik hotspot authentication in practical terms.
3.1 Role of the RADIUS Server in Authentication Requests
The RADIUS server is the decision maker. When a user tries to log in, the router sends an authentication request to the server, and the server checks its own records and answers. The answer either allows the login or rejects it. When the answer allows it, the server can also return policy for that user, which we cover later.
Keep the mental model clean: the router asks, the server decides, and the router enforces the decision. That separation is what lets you change accounts without touching the router.
3.2 How Hotspot Forwards Login Requests to RADIUS
With RADIUS in place, MikroTik Hotspot stops checking only its local entries when a user submits a login. It packages the login as an authentication request and forwards it to the RADIUS server for a central decision. The user sees the same login experience as before. The difference happens behind the scenes, where the answer now comes from the central service instead of a list stored on the router.
This is the core of MikroTik hotspot RADIUS authentication: the router becomes a messenger and an enforcer, and the central server becomes the authority.
3.3 Credential Storage Outside the Router
When credentials are stored outside the router under central control, a change happens once and applies everywhere the service is used. Add an account, reset a password, or retire a customer in the central store, and the next login attempt reflects it. You do not edit each router by hand, and you do not wonder which router still holds an outdated entry.
This is what centralized hotspot credential management buys you: one source of truth, consistent results, and far less repetitive router work.
4. Configuring Hotspot to Use RADIUS for Authentication
Setting up Hotspot to use RADIUS is mostly about relationships: Hotspot needs to know that it should consult RADIUS, it needs to know which server to consult and how to trust it, and it needs to know which services to send to that server. We stay conceptual here, with no commands, clicks, or values, because the purpose of each piece matters more than the exact steps. If your end goal is to connect router billing platform logic to the hotspot so that accounts and payments drive access, getting these relationships right is the first thing to settle.
4.1 Enabling RADIUS Lookup in the Hotspot Server Profile
The Hotspot Server Profile is where the router decides how a given hotspot behaves, including whether logins are checked against RADIUS. Enabling RADIUS lookup there is what turns the whole idea on: it tells Hotspot to send authentication requests to the central server instead of relying only on local entries.
If you are working out how to configure hotspot server profile for RADIUS lookup, think of it as a switch with a purpose. Until the switch is on, the central server never hears about a login, no matter how well everything else is prepared. These hotspot server profile RADIUS settings are the place to look first when behavior does not match what you expect.
4.2 Defining RADIUS Server Address and Shared Secret
Hotspot also needs to know where the RADIUS server is, and the server needs to know it can trust the router. The server address answers the first need. The RADIUS shared secret answers the second: it is the trust relationship between Hotspot and the server, a value both sides know and use to confirm that requests and answers belong to each other.
Treat the shared secret like any other credential. Keep it private, make sure both sides agree on it, and remember that a disagreement between them looks like a failed login even when the user did everything right.
4.3 Selecting Authentication and Accounting Services
Last, you choose which services Hotspot uses with the server. Selecting authentication means logins are checked centrally. Selecting accounting means sessions are reported to the server so you can track them. They solve different problems: authentication decides who gets in, and accounting records what happened afterward.
Most operators want both. Authentication alone gives you central control over entry but leaves you blind to usage. Accounting alone gives you records but no central say over who may log in.
5. Provisioning Users Without Local Router Entries
Once logins are decided centrally, you no longer need to create a matching local entry for every user. A new customer exists in the central store, and the router learns about them at the moment of login. The operational benefit is consistency: there is no duplicate copy of the account on the router that can fall out of step with the real one. If you want the bigger operational picture of how to automate customer access provisioning, this section is the technical heart of it. It also answers a question many operators ask: how to provision hotspot users without local router entries.
5.1 How RADIUS Only Authentication Removes Local Records
With RADIUS only hotspot authentication, the router relies on the central server for every login decision. Because the server already knows each account, the router has nothing to look up locally, so there is no reason to keep a local record per user.
The benefit is practical. Account creation, changes, and removal happen in one place. The router keeps its job of enforcing access, and it no longer doubles as a user database you have to clean up.
5.2 Required Settings for Remote Only User Lookup
Remote only user lookup means Hotspot relies on the central answer and does not fall back on local entries to decide who may log in. In generic terms, you need Hotspot configured to consult RADIUS for authentication, and you need the router to accept the server’s answer as final for these users.
The intent is simple: if the central server says yes, the user is in, and if it says no, the user stays out, regardless of what the router might or might not hold locally. Keep that intent in mind when you review your setup, and avoid mixing in leftover local entries that could muddy the outcome.
5.3 Verifying Logins Without Matching Local Users
To check that this works, think in terms of observable results. Create a test account in the central store only, with no matching local entry on the router, and attempt a login. A successful login confirms that the router is relying on the central decision. A rejected login for a valid central account tells you the request is not reaching the server or not being accepted.
Support that with the router’s logs and the server’s own records. Look for evidence that the request was sent and that an answer came back. You do not need specific log text to follow the story: you are matching a login attempt on the router to a decision on the server.
6. Delivering Per User Policy Through Reply Attributes
Authentication answers a yes or no question. Reply attributes let the same answer carry extra instructions about how the session should behave. When the server approves a login, it can include policy for that specific user, and Hotspot applies it at login time. This is how to deliver per user policy through RADIUS reply attributes without storing any policy on the router per account. We keep everything generic here: no attribute names, values, speeds, or times.
6.1 Common Reply Attributes Used for Session Limits
In generic terms, hotspot RADIUS reply attributes are used to express session limits: how a session should be shaped, and when or how it should end. Each limit is a piece of policy the server attaches to its answer, and the router enforces it for as long as the session runs.
Because the limits come from the central reply, different users on the same router can receive different treatment without any per user setup on the router itself.
6.2 Mapping Access Profiles to Attribute Values
Access profiles are the bridge between your commercial plans and the technical policy. You define a profile for each kind of access you sell, such as a light browsing plan, a standard plan, or a premium plan for heavy users. Each profile maps to a set of attribute values on the server. When a user logs in, the server looks up that user’s profile and returns the matching values.
A practical example: a venue offers a free guest tier and a paid tier. Both use the same hotspot and the same router. The difference lives entirely in the profile mapping, so changing what the paid tier includes means editing the mapping once, and every paid user receives the new policy at their next login.
6.3 Applying Bandwidth and Time Controls Per Login
Bandwidth controls and time controls matter most to operators. Bandwidth controls shape how much capacity a session may use, and time controls shape how long access lasts. Both arrive through the central reply at login, so both are applied per login rather than as permanent settings on the router.
This design keeps policy fresh. If you change a profile centrally, the next login picks up the change, so test a profile change with a new login rather than assuming it will show up on a session that is already running.
7. Tracking Sessions With RADIUS Accounting Records
Authentication tells you who got in. Accounting tells you what happened after that. Hotspot RADIUS accounting sends session records to the central server, and that gives you the visibility you need for support questions, usage review, and, importantly, deciding when an account should be deactivated. If you want to know how to track hotspot sessions with RADIUS accounting, the answer starts with understanding which messages exist and what each one signals.
7.1 Types of Accounting Messages Sent by Hotspot
Hotspot sends accounting messages in several types, and together they describe a session from beginning to end.
A Start record signals that a session has begun. An Interim Update record signals that a session is still active and refreshes what the server knows about it. A Stop record signals that the session has ended. Read in order, they tell you when a user arrived, that they stayed, and when they left.
7.2 Linking Start Stop and Interim Updates to User Sessions
The server ties these records together so they describe the session of a particular user. Start opens the story, Interim Update records keep it current while the session runs, and Stop closes it. That continuity is what gives you visibility: you can see who is online now, review what a finished session looked like, and spot sessions that never closed cleanly.
Interim Update records matter because they keep the server’s picture of a running session current, instead of leaving it to learn about a session only at its start and end.
7.3 Using Accounting Data for Deactivation Decisions
Accounting data feeds the decision to deactivate. If your plans end based on time, the central system compares the accumulated session time against what the account allows. If they end based on usage, it compares the accumulated usage against the allowance. When the account reaches its limit, the central system marks it as expired and blocks further logins.
Notice that the decision happens in the central system, informed by accounting records, and not on the router. That keeps the logic in one place and keeps your limits consistent across every user and every router.
8. Automating Account Creation Renewal and Removal
So far we have covered authentication, policy, and accounting. Now we connect them into a lifecycle: signup creates credentials, renewal extends them, and expiry and revocation retire them. When all three steps run through central credential updates, you never touch the router to onboard, extend, or remove a user. This is how to automate hotspot account renewal and removal in practice, and it is the real payoff of automated router provisioning for operators who are tired of repetitive edits.
If you use a platform such as FLUXI for MikroTik hotspot operations, treat the lifecycle described here as the model to evaluate it against, and confirm with the provider which lifecycle steps are available to you today. The concepts below apply no matter which central system you choose.
8.1 Connecting Signup Systems to Credential Creation
A signup system is whatever collects a new customer: a web form, a front desk tool, or a payment page. The goal is for that system to trigger credential creation in the central store the moment a customer is accepted. The new account appears with the right access profile attached, and the customer can log in without anyone entering anything on the router.
This is the heart of automated hotspot account creation and expiry. When signup and credential creation are linked, onboarding becomes a background event instead of a task.
8.2 Automating Expiry Based on Time or Usage
Expiry is simply an outcome driven by central data. Each account carries its allowance, whether that is based on time or on usage, and the central system compares that allowance with the accounting records described earlier. When the allowance is used up, the account is flagged as expired.
No one has to remember to clean up. Renewal works the same way in reverse: when a customer renews, the central record is updated, and the account becomes valid again at the next login.
8.3 Revoking Access Through Central Credential Updates
Revocation covers expired accounts and cancelled ones. Because the router asks the central server on every login, blocking a user is a matter of updating the central record. The next authentication request is rejected, and the user cannot start a new session.
That is the cleanest answer to the manual cleanup problem from the start of this guide. Expired and cancelled accounts are blocked without editing the router, and you gain a reliable way to enforce policy on every account, every time.
9. Troubleshooting Automated Provisioning Failures
Automation shifts where problems live. Instead of checking router entries, you follow the chain: signup, central record, trust relationship, router configuration, and reply. A calm, ordered approach works best when you are troubleshooting MikroTik hotspot automated provisioning failures. Let authentication rejects, attribute mismatch, and provisioning logs guide you. No commands are needed to reason through them.
9.1 Diagnosing Rejected Authentication Requests
When authentication rejects appear, work through the likely causes in a sensible order.
Start with the central credential state. Does the account exist, is it active, and has it expired or been revoked? A reject that looks mysterious is often a correct reject for an account that was retired.
Next, check the trust relationship. If the RADIUS shared secret differs between the router and the server, or the server does not recognize the router as an allowed client, valid users will be turned away.
Then check service selection. If Hotspot is not set to use RADIUS for authentication, the central server may never receive the request at all, and the user sees a failure that has nothing to do with their account.
9.2 Resolving Attribute Mismatch and Policy Errors
An attribute mismatch happens when the policy the server sends does not line up with what the router expects or what you intended. The symptoms are subtle: a user logs in successfully but gets the wrong treatment, such as limits that do not match their plan, or a session that ends sooner or later than you expected.
To resolve it, go back to your access profiles. Confirm that each profile maps to the policy you meant to deliver, that every plan has a profile, and that no account is attached to the wrong one. Compare what a user was supposed to receive with what the session actually did, and fix the mapping on the server rather than patching individual accounts.
9.3 Logging and Monitoring Provisioning Activity
Provisioning logs give you visibility and a trail to follow. They show when accounts were created, changed, renewed, or revoked, and they let you line those events up against login attempts and sessions. When a customer says their account stopped working, the logs tell you whether the account was changed, expired, or never created in the first place.
Make monitoring a habit and not only a reaction to complaints. Reviewing activity regularly helps you catch signup systems that stopped creating credentials, or accounts that did not expire when they should have, before customers notice.
10. FAQ
10.1 How Does Hotspot Authenticate Users Without Local Entries
Hotspot uses remote only user lookup. Instead of checking a list on the router, it forwards the authentication request to the central RADIUS server and relies on the answer. If the server approves, the user logs in. If it rejects, they do not.
10.2 Which RADIUS Reply Attributes Control User Sessions
Reply attributes carry session limits from the server to the router at login. Those limits cover bandwidth controls and time controls, and the router applies them for the session. The exact attribute names depend on your setup, so confirm them in your own environment.
10.3 How Is RADIUS Accounting Used in Hotspot Deployments
Hotspot sends accounting messages to the server: Start Stop and Interim Update records. Together they give you visibility into active and completed sessions, and they feed deactivation decisions such as expiry based on time or usage.
10.4 What Causes RADIUS Authentication to Fail on Hotspot
Common causes fall into a few groups: credential problems such as an expired or missing account, trust problems such as a mismatched shared secret, service selection problems such as RADIUS not being enabled for authentication, and policy mismatch between profiles and expected behavior.
10.5 How Are Expired Accounts Automatically Blocked
Expiry and revocation happen through central credential updates. When an account reaches its limit or is cancelled, the central record changes, and the next authentication request is rejected. You do not edit the router.
10.6 Can Per User Limits Be Changed Without Editing the Router
Yes. Per user policy lives centrally and is delivered at login, so you change the profile or the account on the server and the new limits apply at the user’s next login, with no manual router edits.