Goal

Here’s how to get your published mobile app talking to your WordPress site again after you’ve moved it to a new host, cloned production into staging (or staging back into production), or restored from a backup.

Your app itself never changes — it’s a compiled iOS/Android binary already sitting in the App Store and Google Play. What can change is the site it’s pointing at, plus a handful of values stored in your database that tie this WordPress install to your customer record on the WPMAM (Tiny Screen Labs) enrollment server. A migration can leave those values pointing at the wrong place. Below are the four most common causes, in the order you should check them.

Prerequisites

• WordPress admin access (manage_options) on the site the app is supposed to talk to.
• The site is reachable at its real public URL over HTTPS (not a temporary host preview URL or an IP address).
• You know which install is meant to serve the live app: production, not staging. This matters — pointing the live app at a staging copy is the single most common post-migration failure.
• Ideally, access to your hosting/SQL tools or a database plugin, in case you need to peek at a stored option value — though most steps can be done from the admin screens alone.

Background: what a migration can break

Four things tie your published app to this specific WordPress install, and a move, clone, or restore can knock any of them loose.

Think of the account code as a frozen contract: roughly 2,000 customer sites already have a value stored, every app references it, and the whole publish pipeline depends on it. Handle it carefully — your goal is to land the correct code on the correct site, not to invent a new one.

Steps

1. Confirm which site the app should be hitting

Start by opening Mobile App Manager → Publish App — it reads the site URL at runtime (get_site_url()), so whatever it shows reflects the install you’re actually logged into right now.

• If you’re on staging and the live app is misbehaving, stop here — you almost certainly want to be on production. The app’s API endpoint was frozen into the build when you published; it points at the URL the site had at that moment.
• Check that your production WordPress Settings → General shows the exact public URL — correct scheme, correct host, no leftover staging or host-preview domain. If it’s wrong, fix it here first and re-test the app before doing anything else.

If the app’s baked-in endpoint doesn’t match your live URL at all — say, you genuinely changed domains — no database edit here will fix it. The app needs a new build published so the new endpoint gets compiled in. Work through the remaining steps to get the site healthy, then re-publish.

2. Bust the verification cache so the Publish page re-checks

The Publish page only checks your account code against WPMAM once a day at most, then caches the result in a transient — WordPress’s term for a temporary stored value — named mam_account_code_verified. Right after a migration, that cache can still be “warm” with a stale result, which hides a real mismatch and stops the page’s built-in self-correction from ever kicking in.

Clear the relevant transients to force a fresh check. The two that matter are the account-code verification result and the cached subscription status. If you have a transient-management tool, delete:

• the account-code verification transient (mam_account_code_verified)
• the publish subscription status transient (mam_publish_subscription_status)

No transient tool handy? A full object-cache flush works too. Then reload Publish App.

3. Let the account-code check reconcile (or check it manually)

When the Publish page loads with a cold cache, it asks WPMAM “what account code do you have on file for this site URL?” and compares the answer to what is stored locally:

• If WPMAM returns a code and it differs from the stored one, the page corrects the local value to match what WPMAM has for this URL and clears the cached subscription status. This is the intended behavior when, for example, a staging code ended up on a production site.
• If WPMAM returns nothing (the URL it has on file doesn’t match your current URL, or the server is briefly unreachable), the page leaves the local value alone and shows a soft warning rather than hard-blocking you.

So in the common case — a clone that copied the wrong code onto an otherwise correctly-URL’d site — just reloading the Publish page with a cleared cache reconciles the account code for you, automatically.

Caution: this reconciliation keys off your current site URL. If two installs (prod and staging) are both reachable under URLs WPMAM recognizes, make sure each one is enrolled under its own URL on the server. If you’re unsure which code is correct, or the page keeps flip-flopping the value, stop and contact support rather than guessing — an account code pointed at the wrong customer can misroute publishes and push notifications to another customer’s store account.

4. Neutralize the staging copy so it can’t fight production

A clone leaves you with a second site that thinks it’s the app’s backend. To stop it from racing production for the same account code or firing off stray requests:

• Flag the copy as a staging site if your install supports it (the publish flow checks an is_staging marker). Mark the non-live copy, not production.
• On the copy you do not want serving the app, you can clear the stored account code entirely. MAM_Account_Code_Manager::delete() is the supported reset for “site reset / staging clone reset” — it removes both the current and legacy stored keys so a stale value can’t resurface. Leave production’s code intact.
• Make sure only the production install is enrolled at the live public URL on WPMAM.

5. Re-verify push and publish credentials

Some credential paths — push notification routing, publish/Fastlane authentication — key off the account code on WPMAM’s side. Once the account code is correct on the live site:

• Re-open Publish App and confirm the page no longer shows an account-code or subscription warning.
• If push notifications had stopped working, have a test user log out and back in of the mobile app. Device push tokens live per-user as user meta — WordPress’s per-user custom-data store — and refresh on login, so signing back in re-registers the device against the now-correct backend. A clone that copied stale tokens between sites heals the same way: by logging back in from the real devices, not by editing the database.

6. Confirm app role/content cloning still works (if you use it)

If your workflow relies on admin cloning — previewing the app as another role — or on copying one role’s app content into another, give that a re-test after the migration. Both the “clone role content” admin action and the “view as role” preview run against your current install’s stored content, so the account code doesn’t touch them — but it’s easy to mistake one for a backend problem. If admin cloning works fine but real devices don’t, you’re looking at account-code/URL drift (steps 1–5), not a content issue.

How to tell it worked

• Publish App loads with no account-code mismatch warning and no subscription warning.
• The stored account code on the live site matches the code WPMAM has for the live URL.
• A real device, after the user logs out and back in, loads app content and receives a test push.
• Your staging/restored copy no longer holds the live account code (or is flagged as staging), so it can’t interfere.

When to stop and contact support

Open a support ticket rather than continuing to edit values if:

• You don’t know which of two installs owns the live account code, or the value won’t stay corrected.
• WPMAM has no record for your current URL because you genuinely changed domains — you’ll likely need a re-enrollment plus a new app build, and support can confirm the right sequence.
• Push or publish still routes to the wrong place after the account code looks correct — credential paths on the server may need re-pointing.

The account code is a frozen, customer-spanning contract — misrouting it can affect store submissions and push notifications for someone else’s account entirely. When in doubt, get it confirmed rather than reset.

Related

• Integration: Account code and enrollment server — the MAM_Account_Code_Manager API, the verification cache, and graceful degradation.
• Recipe: Publish your app to iOS and Android — re-publishing a build after a domain change.
• Recipe: Customer enrollment and account code — first-time enrollment and re-enrollment.