Available on all subscription plans
The Credential Manager — including the full credential pool, automatic top-up controls, and bulk management tools — is now a core platform feature available to all QuuPass subscribers. There are no tier restrictions on credential management.
The Credential Manager (Dashboard → Credential Manager) provides a unified view of every credential across all portals. You can search, filter, tag, bulk-delete, copy passphrases, and print credential sheets without having to navigate portal by portal.
The Credential Manager groups credentials into two categories, shown as tabs:
Credentials issued to specific guests. Each has an identifiable name and optionally a guest name, email, or expiry date. Created when a guest visits a public portal, or bulk-generated by staff through the admin dashboard.
Pre-generated credentials sitting in a shared pool. When a guest visits the portal, one pool credential is assigned from AVAILABLE to ISSUED. Useful for print-ahead access cards or event badges where credentials need to be physically handed out.
| Field | Description |
|---|---|
| Credential name | Auto-generated or custom label (e.g. "Guest-3F2A"). Shown to staff only. |
| Guest name | Optional name provided by the guest when visiting the portal. |
| Guest email | Optional email collected at the portal, if the portal is configured to request it. |
| Passphrase | The Wi-Fi password used as the IPSK. Typically a 12-word passphrase or a short alphanumeric code depending on portal configuration. |
| Expiry date | When this credential will stop working. After expiry, it is automatically removed from Meraki during the next cleanup cycle. |
| Created at | Timestamp when the credential was first generated. Rendered in the time zone configured in Account Settings. |
| Last used | On plans with RADIUS accounting: the last time Meraki reported an authentication using this credential. Only populated when RADIUS accounting is enabled on your plan and network, and rendered in the time zone configured in Account Settings. |
| Source | Where the credential was created: GUEST (portal), ADMIN_BULK (staff dashboard), or POOL (from pool). |
| Tags | Freeform labels you attach to help organise and filter credentials (e.g. "VIP", "Event A", "Floor 3"). |
| Group policy | The Meraki group policy assigned when this credential was provisioned. |
| Meraki identity ID | The internal Meraki API identifier for this IPSK identity. Shown for debugging purposes. |
Copies the credential passphrase to the clipboard. The passphrase is hidden by default (shown as ••••••) and unmasked only when you explicitly click Show.
Opens a print-friendly sheet containing the credential passphrase and QR code, suitable for handing to a guest at a front desk or attaching to a welcome pack.
Displays the QR code for this credential in a modal. Guests can scan it with their phone camera to connect without typing the passphrase.
Add or remove freeform tags on a credential to categorise it. Tags are searchable and filterable.
Removes the credential from both QuuPass and the Meraki Dashboard immediately. The guest will lose Wi-Fi access on the next re-authentication attempt.
Select multiple credentials using the checkboxes and delete them all in one operation. Useful for cleaning up after an event or removing a batch of expired guest accounts.
Available from the Credentials page — removes all credentials past their expiry date from both QuuPass and Meraki in one action.
The search bar filters credentials in real time by name, guest name, email, passphrase, or tag. Results are paginated to keep performance snappy for accounts with thousands of credentials.
Pool credentials work on both Mode A (Meraki IPSK) and Mode B (RADIUS) portals. The pool acts as a live credential cache: when a guest opens the portal, an AVAILABLE credential is atomically claimed and flipped to ISSUED. If the pool runs dry, the portal falls back to generating a credential on demand via the respective API.
The pool tab shows Total, Available, and Issued counts. You can manually top up the pool at any time using the “Top up now” button, or configure automatic replenishment from the Credential Pool tab on the portal’s Edit page.
Guest credential claim
Pool auto-replenishment
The pool can also be used for physical credential distribution — pre-print QR codes or passphrases to hand out at reception, on access cards, or in event packs. Manually-distributed credentials change to ISSUED status on first Wi-Fi use.
Pool settings live on a dedicated Credential Pool tab in each portal’s Edit page (Portal Settings → Credential Pool). The tab contains two cards:
| Mode | When does the cron replenish? | Best for |
|---|---|---|
| Threshold | Available credentials drop below X% of target | Most venues — efficient, only runs when needed |
| Scheduled | N hours have elapsed since last replenishment | Short-lived credentials where time-based refresh matters |
| Both | Either threshold OR schedule condition is met | High-traffic / short-expiry portals (events, conferences) |
| Manual only | Never — cron is disabled for this portal | Full admin control; use "Top up now" on demand |
Every 5 minutes the background replenishment cron evaluates each portal. The following diagram shows the full decision tree — and also what happens when you click Save on the portal edit page (which triggers the same replenishment path immediately).
Replenish: create (target − available) credentials
Rate-limited · 200 ms between API calls · Meraki limit: 5,000 identityPsks / SSID
lastPoolReplenishedAt · Done ✓targetPoolSize > 0, the portal immediately calls the replenish endpoint. The result (“Pool synced — 12 credentials added (50/50 available)” or “Pool already at target”) is shown below the Save button for 8 seconds.The credential pool is a powerful feature, but larger deployments need to consider its impact on both the admin experience and the underlying Meraki API limits. The guidance below is based on current understanding; some limits require further investigation tied to network topology.
| Limit | Value | Notes |
|---|---|---|
| identityPsks per SSID | 5,000 | Hard Meraki platform cap — applies across all portals sharing the same SSID |
| Max target pool size (per portal) | 500 | QuuPass UI limit, set conservatively below the per-SSID cap |
| API rate delay | 200 ms between calls | Each credential creation is an individual Meraki API call with a built-in delay to avoid rate limiting |
| Cron interval | Every 5 minutes | Minimum time between automatic top-up evaluations |
As pool size and credential count grow, two friction points emerge for admins and the system:
A large Credential Manager list (thousands of credentials) makes search and bulk operations slower. Consider using shorter expiry windows combined with the cleanup cron to keep the active set manageable. Tags and per-portal filtering help narrow scope when reviewing.
A large top-up fill (e.g. restoring a 400-credential pool from zero) takes 400 × 200 ms = ~80 seconds in a single run. During this window the cron is occupied and other portals may not be evaluated. Staging top-ups across multiple 5-minute cron cycles (via smaller targets or higher thresholds) distributes this load.
Future investigation: IAP count & pool sizing
The optimal pool size for a venue is likely correlated with the number of Meraki Wireless Access Points (IAPs) in the network — more APs serve more concurrent guests, which means faster pool depletion. We do not yet have per-network IAP count data surfaced in QuuPass. A future enhancement will query the Meraki API for AP count and surface it alongside pool configuration guidance, enabling smarter default recommendations (e.g. target = 10 × AP count).
For now, use venue peak occupancy as a proxy: a 200-person venue with 15-minute credential expiry might need a pool of 50–150 credentials refreshed every 1–2 hours.
On the Starter and Pro (without bundled RADIUS) tiers, QuuPass provisions guest credentials directly through the Meraki IPSK API (Mode A). This works well for steady-state guest traffic but has architectural constraints that matter when visitor volume is high or when event surges occur.
How IPSK credential creation works (Mode A)
Each unique credential requires an individual Meraki API call to create an identityPsk object. QuuPass rate-limits these to one per 200 ms to avoid hitting Meraki’s API throttle. At that rate, creating 100 credentials takes ~20 seconds; 300 credentials takes ~60 seconds. This is fine for background pool replenishment but becomes a bottleneck when many guests arrive simultaneously to a portal without a pre-warmed pool.
The table below gives rough guidance on when IPSK (Mode A) handles traffic comfortably, when the pool must be carefully sized, and when RADIUS becomes the better choice. These are approximations — actual impact depends on credential expiry length and the number of concurrent portal sessions.
| Scenario | Approx. daily uniques | IPSK (Mode A) | Recommendation |
|---|---|---|---|
| Small office / café | < 50 | ✅ Comfortable | Any top-up mode works. Threshold at 20% is sufficient. |
| Mid-size venue (hotel, restaurant) | 50 – 200 | ✅ Works well | Keep a pool of 50–100 credentials. Threshold + Scheduled (every 4–6 h). |
| Busy venue or regular events | 200 – 500 | ⚠️ Pool required | Pool of 150–300 essential. Scheduled every 1–2 h. Monitor AVAILABLE count regularly. |
| Event surge (concert, conference) | 500 – 1,000+ | ⚠️ High risk | Pre-warm pool to maximum before the event. Pool may still exhaust mid-event causing on-demand fallback delays. Evaluate RADIUS tier. |
| Large venue / recurring high traffic | 1,000+ | ❌ Limit reached | IPSK (Mode A) is not suitable at this scale. Upgrade to QuuPass RADIUS to eliminate per-credential API calls. |
Pool AVAILABLE count regularly hits zero
Means the cron cannot keep up with consumption. Guests are experiencing on-demand fallback delays at the portal.
Guests report slow portal load during busy periods
On-demand IPSK creation takes 1–3 seconds per credential when the pool is empty. This is visible to guests as a spinner or delay before the passphrase appears.
Credential Manager shows 3,000+ active credentials
You are approaching the 5,000 per-SSID hard cap. With multiple portals sharing an SSID, this limit is shared across all of them.
Top-up cron is frequently running for long stretches
A large deficit fill (300+ credentials) takes 60+ seconds per cron cycle. During this time other portals on the cron queue may not be evaluated.
When to evaluate the QuuPass RADIUS tier
If you are regularly hitting any of the signs above — or if your venue hosts events where hundreds of guests arrive within the same hour — the QuuPass RADIUS tier (Mode B) eliminates the per-credential API bottleneck entirely. With RADIUS, credentials are issued in real time at authentication without touching the Meraki IPSK API, so there is no pool to manage and no 5,000-credential ceiling per SSID.
Contact your QuuPass account manager or visit the subscription settings to compare plans.
On Pro and Campus Plus plans, Meraki sends RADIUS accounting messages back to QuuPass each time a guest authenticates. This populates the Last used field on each credential, giving you real activity visibility — not just when the credential was issued, but when the guest most recently connected to the network.