Goal

Get your site enrolled so it has a real MAM account code — the credential that unlocks plugin updates, entitlement checks, and app publishing. When you first activate MAM Suite, it tries to register your site automatically with the licensing server and get a code back. If that handshake never finished, you’re left with no code (or an offline placeholder standing in for one), and everything that depends on licensing just won’t work.

Here’s how to tell which of the three usual culprits broke your enrollment, and how to fix it.

Prerequisites

• Admin access to Mobile App Manager (the manage_options capability).
• The ability to reach your hosting control panel or ask your host about outbound network rules — one of the failure modes is server-side.
• A few minutes to reload an admin page, since enrollment retries on admin page loads.

How auto-enrollment is supposed to work

Every time you load an admin page, MAM Suite checks whether your site already has an account code. If it doesn’t, your site reaches out over HTTPS to the licensing server (wpmobileappmanager.com), handing it your site’s admin-ajax.php URL. The server writes back JSON with an account_code, and MAM Suite stores it. After that, the check is just a quick lookup — once you’re enrolled, this whole process barely registers.

Three things can get in the way:

1. Outbound HTTP is blocked. If your server can’t reach wpmobileappmanager.com, the request fails and no code comes back — and it’ll keep failing on every admin load until something changes.
2. The site enrolled while offline (the LOCALHOST sentinel). If MAM Suite’s connectivity check decides there’s no internet at activation time, it stores the placeholder value LOCALHOST instead of a real code. The site looks enrolled — there’s a value sitting there — but it’s a stand-in, not something the server issued, and licensing features see right through it as “not really enrolled.”
3. The site is the source host (self-request). When the site’s own host is wpmobileappmanager.com (or a subdomain of it), enrollment is deliberately skipped — otherwise the server would end up calling itself in a deadlock. You’ll mostly run into this on internal or staging copies of the licensing site.

Steps

1. Confirm whether you actually have a code

Start by checking your site’s stored account code. The easiest place to look is Mobile App Manager — anywhere the admin shows your account code or licensing status. What you find puts you in one of three cases:

• A normal-looking code (a real value, not the word LOCALHOST): you’re enrolled. Whatever’s going wrong is a separate issue — stop here and look at the specific feature that’s failing.
• The literal value LOCALHOST: you’ve hit failure mode 2. Head to Step 3.
• Empty / no code at all: enrollment never finished. Continue to Step 2.

If you’re comfortable digging into the database or WP-CLI, the option to check is mam-account-code (older sites may still carry the legacy local-app-account_code). An empty option means no enrollment; the string LOCALHOST means the offline placeholder.

2. Check that outbound HTTPS is allowed (failure mode 1)

Enrollment depends on your server — not your browser — reaching the licensing server over HTTPS. Plenty of hosts block or firewall outbound connections, and the WordPress constant WP_HTTP_BLOCK_EXTERNAL can shut them down at the application level too.

Check these three things:

• WP_HTTP_BLOCK_EXTERNAL is not blocking the licensing host. If your wp-config.php has this constant set to true, either remove it or add wpmobileappmanager.com to the WP_ACCESSIBLE_HOSTS allowlist.
• The host’s firewall allows outbound HTTPS to wpmobileappmanager.com. If you’re not sure, just ask your host whether outbound requests to external domains are allowed — a lot of managed or locked-down environments deny them by default.
• DNS and TLS resolve correctly from the server. MAM decides whether you’re online by sending a quick connectivity probe to a small endpoint on the licensing server — if that probe can’t complete within a few seconds, your site gets treated as offline.

Once you’ve confirmed outbound HTTPS is open, reload an admin page — auto-enrollment runs again on every admin load, so a successful round trip will store a real code this time. Then re-check Step 1.

3. Clear the offline placeholder, then re-enroll (failure mode 2)

If your stored value is LOCALHOST, your site registered itself while it believed it had no internet. A real code won’t overwrite that placeholder on its own — as far as the system’s concerned, “a value is present” is good enough. So you need to clear it out and let enrollment run fresh:

1. Fix connectivity first (Step 2) — there’s no point re-enrolling until your server can actually reach wpmobileappmanager.com.
2. Remove the stored account code so it’s empty instead of LOCALHOST. If MAM’s tooling exposes a control for this, use it — that’s the supported path. Otherwise, delete the mam-account-code option (and the legacy local-app-account_code, if it’s present) via WP-CLI or the database directly.
3. Reload an admin page. With the code empty and the network reachable, the next admin load will attempt a fresh enrollment and store the real code.

Re-check Step 1 to confirm you’ve got a normal code now, not the placeholder.

4. Handle the source-host / self-request case (failure mode 3)

If your site’s host is wpmobileappmanager.com or a subdomain of it, auto-enrollment is intentionally skipped to avoid a self-request deadlock — this site will never enroll itself automatically, and that’s by design. Almost always, this means you’re looking at an internal or staging copy of the licensing site, not a customer site.

If you genuinely need a code on a site like this, it has to be set manually — it won’t be fetched. Get the correct account code out of band and store it directly (through MAM tooling if it’s available, or by writing the mam-account-code option yourself). Don’t try to “fix” the skip; it’s there to protect the licensing server from calling itself.

5. Confirm the site is now properly enrolled

Once you’ve worked through the steps above, confirm:

• The stored account code is a real value, not empty and not LOCALHOST.
• Licensing-dependent features start behaving — plugin update checks and entitlement-gated features that previously did nothing, for instance. These features explicitly treat both an empty code and the LOCALHOST placeholder as “no code,” so a real code is what switches them on.

A note on staging copies and URL changes

Clone a production site to staging, or move domains, and the account code comes along for the ride in the database — the new copy still carries the old site’s code. MAM Suite notices the site URL no longer matches what it originally registered, and shows an admin notice asking you to confirm the change before it re-registers under the new URL. It never silently swaps your account code just because the URL changed. If you see that “Site URL Changed / your site URL has changed…” notice asking whether this is your production URL or a staging site, that’s expected after a move — confirm it, and the site re-enrolls under the new address.

This is a different situation than “never got a code” — here, a code already exists, and the only question is which URL it’s bound to.

Verification

• Mobile App Manager shows a real account code (not empty, not LOCALHOST).
• Reloading an admin page no longer triggers a fresh enrollment attempt (the code is present, so the check short-circuits).
• Outbound HTTPS from the server to wpmobileappmanager.com succeeds.
• Licensing-dependent features (plugin updates, entitlements, publishing) work as expected.

Related

• Getting started: Activate MAM Suite and enroll your site — the happy-path setup this recipe recovers.
• Troubleshooting: My site URL changed (staging vs production) — the URL-change notice and re-registration flow.
• Reference: Account code storage and the LOCALHOST sentinel — what the stored value means and which features gate on it.

What’s next

Once you’ve got a real account code, confirm your plugin entitlements are recognized, run a plugin update check, and carry on with app setup. If features still act unlicensed after enrollment, note down the exact feature and the stored code value before you reach out — that lets support tell an empty code from the LOCALHOST placeholder at a glance.