The one-line version

Your account code is the single string that says “this WordPress site belongs to this customer, and this customer’s app.” It is assigned automatically when your site enrolls with Tiny Screen Labs, it is stored once, and almost everything that connects your website to your mobile app — the content the app pulls, the preview your phone shows, the build that goes to the App Store — relies on it being correct and stable.

You will rarely touch it. But understanding what it is makes the rest of MAM Suite easier to reason about, and it tells you exactly what to do (and what not to do) on the day your site moves to a new URL.

Why an app needs a “which site am I?” answer

MAM Suite turns a WordPress site into a native mobile app. The app on the phone is mostly an empty shell at install time: it knows how to render screens, but the actual content — your posts, products, menus, app settings — lives on your WordPress site and is fetched at runtime.

That raises a routing question. There are roughly two thousand customer sites in the MAM ecosystem. When a phone, a preview, or the publishing pipeline needs to talk to “the right site,” something has to identify which one. The account code is that identifier. It is the stable handle that the central server (WPMAM, run by Tiny Screen Labs) uses to map a customer to their site and their app.

Think of it the way WooCommerce thinks about a store: the store has an identity that orders, payments, and shipping all hang off of. The account code is your app’s store identity.

How a site gets its account code: enrollment

You don’t pick an account code, and you don’t type one in. It is assigned during enrollment, automatically, the first time the plugin runs in your WordPress admin.

Enrollment is handled by the site-enrollment routine in MAM Main (includes/setup-wizard/mam-site-enrollment.php). On admin page loads it does a fast check, and the very first time it sees an un-enrolled site it performs a handshake with the enrollment server:

1. It reads this site’s admin-AJAX URL — the WordPress endpoint the mobile app will eventually call to fetch content.
2. It calls the WPMAM enrollment endpoint, handing over that URL (and your download token, if one is configured).
3. WPMAM responds with an account code assigned to this site.
4. The routine stores three things locally and then gets out of the way: the account code, a prod-account anchor (more on this below), and the AJAX URL it registered.

After that first successful handshake, the early check sees that a code already exists and returns immediately — enrollment does not run again. The account code is now the durable link between your site and your customer record.

The MAM source site itself (wpmobileappmanager.com) is deliberately skipped by this routine, so the server never tries to enroll with itself.

The prod-account anchor: your “real” account, even on copies

Here is the part that trips people up, so it’s worth being explicit.

Sites get cloned. You spin up a staging copy, a developer makes a dev environment, you migrate to a new host. Each of those copies, left alone, would enroll and could be assigned its own account code. If every clone got treated as a brand-new customer, your content, your app settings, and — worst case — your App Store publishing could end up pointed at the wrong place.

To prevent that, MAM stores a prod-account anchor alongside the account code: a record of which “main” account this site really belongs to. During the enrollment handshake the server returns both an account code for this specific site and a main account code; the main code is saved as the anchor. When a site re-enrolls (for example after being moved), it sends its anchor back to the server as the parent account, so the server can keep the copy associated with the original customer instead of minting a stranger.

Existing sites that enrolled before the anchor existed are handled gracefully: their current account code is treated as their anchor and copied into the anchor slot once, so nothing has to be re-issued.

The practical upshot: the prod-account anchor is what keeps “this is still the same customer” true across clones and migrations, so a staging copy can’t accidentally hijack — or get hijacked by — your production app’s identity.

What the account code actually routes

Once your site is enrolled, the account code (and the registered URL it travels with) is what makes the three core MAM activities land in the right place.

Content the app pulls. The mobile app fetches its content from the site at the URL that was registered during enrollment. The account code is the server-side identity that registration is bound to, so the phone ends up talking to your WordPress site and pulling your posts, products, and app settings — not some other customer’s.

Previews. When you preview your app — for example checking how a change looks on a phone before you publish — the preview is rendering against the same registered site. It’s the same routing as production content, which is exactly why a preview is a faithful dress rehearsal: same site identity, same content source.

Publishes. This is the highest-stakes one. The publish pipeline (Mobile App Manager -> Publish Your App) verifies the account code against the enrollment server before it submits a build. Because the account code is how Tiny Screen Labs keys a customer’s App Store Connect and Google Play accounts, that verification is what ensures your build goes to your store accounts. A wrong or drifted code here is not a cosmetic problem — it’s the difference between shipping to the right developer account and the wrong one.

Other parts of the suite lean on it too: plugin entitlement (which sibling plugins your site is licensed for) is keyed by account code, push-notification credentials are associated with it on the server side, and some plugins include it in the app payload for analytics keying.

Why it’s treated as “frozen”

Because so much hangs off this one value, the account code is one of the most carefully protected settings in MAM Suite. Roughly two thousand live sites have a value stored, real mobile apps in customers’ hands reference it, and the publish pipeline depends on it. Changing it casually would break the link between site and app.

A few consequences of that, expressed as behavior you’ll actually see:

• It is written through one controlled path. All writes go through the account-code manager (MAM_Account_Code_Manager), which is the only legitimate way to set or clear the value. Reading it elsewhere is fine; writing it by hand is not.
• The system never silently rewrites it. If your local code and the server’s record disagree, MAM surfaces the mismatch and stops — it does not auto-correct. Auto-correcting could reroute a publish to the wrong customer’s store account, which is precisely the disaster the whole design exists to avoid.
• A special “offline” state exists. A site that came up without being able to reach the enrollment server can carry a LOCALHOST sentinel — it counts as “set” but signals that enrollment hasn’t truly completed yet.

What this means for you as an admin

For day-to-day work, the account code is invisible and that’s the point: you build your app, the right content flows, previews are faithful, and publishes go to the right accounts, all without you thinking about it.

The one moment it surfaces is when your site URL changes — a domain move, an HTTPS switch, a host migration. The enrollment routine notices the registered URL no longer matches the live one and shows an admin notice: Your site URL has changed… Update your app registration. Clicking that button re-runs the handshake under the new URL (carrying your prod-account anchor along) so the link stays intact. You confirm; the system never changes the account code behind your back.

And if you ever hit a verification mismatch on the publish page, the correct move is not to edit anything by hand. A mismatch almost always means the site was migrated or cloned, and the fix is to contact Tiny Screen Labs support with your site URL so they can re-issue enrollment cleanly. Editing the value directly risks pointing your app — or your App Store submission — at the wrong customer.

The other two situations you might run into resolve the same way — by letting enrollment do its job, never by typing a value in:

• The site shows as not enrolled (no code yet). Load the admin so enrollment can complete its handshake, or run the setup wizard (Mobile App Manager → Setup Wizard) to walk it through. The code is issued by Tiny Screen Labs, not generated on your site.
• You see LOCALHOST stored. The site came up offline and hasn’t truly enrolled yet. Once it can reach the enrollment server, complete enrollment and the placeholder is replaced with a real code.

How this connects to the rest of MAM Suite

• The account code is the foundation the publish pipeline stands on; the publish page’s pre-flight verification is the safety check that the link is still sound.
• It’s the key behind plugin entitlement, which is how your site knows which sibling plugins it’s licensed to use.
• It travels with the registered AJAX URL, which is the actual endpoint your mobile app and previews fetch from — the URL is the address, the account code is the identity.

Related

• Recipe: Customer enrollment and account code — the hands-on version: inspecting the value, running the wizard, and what to do when verification fails.
• Recipe: Publish your app to iOS and Android — where account-code verification gates the build.
• Integration: Account code and enrollment server — the developer-facing reference for the manager class, the handshake, and the hooks.
• Frozen public contracts reference — why this option, and a handful of others, must not be renamed.

Draft for review. Grounded in mam-main/includes/setup-wizard/mam-site-enrollment.php, mam-main/includes/account-code/class-mam-account-code-manager.php, and the existing mam-main user docs on enrollment and the account code.