Goal

Someone can’t get into your MAM app — maybe a user reported it, maybe you hit the login screen yourself during testing and got turned away. Either way, this guide helps you find the cause and fix it.

Almost every login failure falls into one of four buckets:

1. Wrong credentials — the email/password don’t match, or the account doesn’t exist.
2. Misconfigured social login — Apple/Google sign-in is enabled but the Google client ID (or token verification) is wrong or missing.
3. A code that never arrives — the email verification or SMS phone code isn’t reaching the user.
4. Role not allowed on the app — the account is valid, the password is right, but the user’s WordPress role isn’t on the app’s allowed-roles list.

Your fastest route to the fix is the exact message the app showed. The login handler returns a specific message for each failure, so the wording usually points straight at the right bucket.

Prerequisites

• Access to Mobile App Manager in WordPress admin for the app in question.
• The ability to edit WordPress users (to check roles and account state).
• For social-login issues: access to the Google Cloud Console project that owns the OAuth client ID.
• For code-delivery issues: knowledge of which notification channels (email / SMS) are configured for the app. SMS requires an SMS provider plugin to be active.

Step 1 — Read the error message and match it to a bucket

The app shows you exactly what the login handler returned — use the table below to jump straight to the right section. Wording may be lightly customized per app, so match on intent, not exact text.

If you don’t have the exact message — the user just says “it won’t let me in” — start at Step 2 and work your way down.

Step 2 — Rule out wrong credentials

This is the most common cause, and the cheapest one to rule out.

1. Confirm the account exists. In WordPress admin, go to Users and search for the email the person is typing. The app matches on email first, then on username. If there’s no matching user, the app returns “No account found” — they need to sign up, or you’re looking at a typo in the email.
2. Confirm they’re using email, not a display name. Users often type a name instead — the login expects the email address (or the WordPress login), lowercased and trimmed.
3. Reset the password to test. If the account exists but the password is rejected, have the user run Forgot Password from the login screen, or reset it for them in WordPress admin. A successful reset both sets a new password and marks the email verified.
4. Check for a rate-limit lockout. Login and signup are rate-limited per device — roughly five attempts within a ten-minute window. After that the app returns “Too many login attempts.” This clears on its own after the window, or on the next successful login. If a user has been hammering the screen, have them wait a few minutes before trying again.

Credentials check out but they’re still locked out? Move on — the problem lies in config, codes, or role.

Step 3 — Check social / Google sign-in configuration

This applies only if your app shows Sign in with Apple / Sign in with Google buttons, which are controlled by the Allow user to sign up with Apple and Google setting on the login screen.

1. Confirm the social buttons should even be there. In Mobile App Manager, open the app’s Login settings and check Allow user to sign up with Apple and Google. If it’s off but users expect social login, that’s your fix.
2. Verify the Google client ID. Google sign-in additionally requires the Google Login API (the Google OAuth client ID) to be set in the Login settings. Get this value from your project’s OAuth credentials in the Google Cloud Console. A missing or wrong client ID is the usual cause of Google login failing while Apple works.
3. Watch for “Token audience mismatch.” When server-side Google token verification is enabled, the app validates that the token’s audience matches the configured client ID. A mismatch here almost always means the client ID in the app settings doesn’t match the one the mobile app was built against. Make sure the same OAuth client ID is used in both places.
4. “Invalid or expired Google token” / “Invalid token issuer.” These point at the token itself rather than your settings — usually a stale token or a build/config mismatch on the mobile side. Have the user fully close and reopen the app to get a fresh token, and confirm the app build is pointed at the right Google project.
5. Apple-specific messages (“Missing Apple user identifier”, “Apple identity mismatch”, “Invalid or expired Apple token”) indicate the Apple Sign-In payload didn’t come through cleanly. This is generally a device/build issue rather than a WordPress setting; retry on the device first.

Note: social token verification is an optional hardening step. Turn it off, and the app simply trusts the identity the device sends — these verification messages won’t show up, so a wrong client ID instead looks like Google login quietly failing to create a session.

Step 4 — Check that codes are arriving (email verification & SMS)

MAM uses short codes in three places: email verification at signup, lost-password reset, and SMS phone-number validation. “I never got the code” is really a few different checks depending on which one’s failing.

Email verification at signup

1. Is email validation even required? The Require email validation during account setup setting controls whether a new account stays inactive until the user confirms a code. If it’s on, a user who skips the code sees “Email address not verified” on their next login attempt.
2. The code is time-limited. Signup verification codes expire after about 15 minutes. “Verification code expired” means they need a fresh one — have them restart signup or use Forgot Password, which also clears the unverified state on success.
3. Code not received at all? Check that your app’s transactional email is actually sending (the same email path used for any MAM notification). Look in spam, confirm the address has no typo, and verify the site can send mail. The verification email goes to the address the user signed up with.

Lost-password code

• The reset code is also time-limited (~15 minutes) and is delivered through the same notification path. “The code you entered is not valid” means either a mistyped code or an expired one — request a new code and try again.

SMS phone-number validation

1. An SMS provider must be active. Phone-code validation routes the code through the MAM notification dispatcher on the SMS channel. If no SMS plugin/provider is configured, codes can’t be sent. This is a server-side prerequisite, not an app setting.
2. Phone number formatting. The phone code flow strips everything except digits before sending, so formatting characters are tolerated — but the number still has to be a real, reachable mobile number.
3. Codes are time-limited and reused within the window. A phone validation code is valid for about 30 minutes; requesting again within that window re-sends the same code rather than minting a new one. If a user requests several and enters an old one, it can still be valid — but a truly expired one needs a fresh request.
4. The Send Code / Sign Up Code Reminder labels on the Login settings only change wording; they don’t affect delivery. If users can’t find where the code went, the Sign Up Code Reminder helper text is the right place to tell them to check email/SMS.

Step 5 — Confirm the user’s role is allowed on the app

This is the bucket people miss most often — because everything about the credentials is right. The app message is “The role for this user login is not setup on the app.”

Once the password checks out, MAM compares the user’s WordPress role against the app’s allowed roles list. If none of their roles is enabled for this app, the login gets rejected and the device session cleared — even though the email and password were exactly right.

1. Find the user’s role. In WordPress admin, open the user and note their role(s) (Subscriber, Customer, a custom role, etc.).
2. Check that role is enabled for the app. In Mobile App Manager, open the app’s user roles / roles to manage configuration and confirm the user’s role is turned on. A role that isn’t enabled there will always be rejected at login.
3. Check the default new-user role. New accounts created through signup are assigned the app’s configured default role (falling back to Subscriber). If your default role isn’t on the allowed list, brand-new signups will be created and then immediately blocked at login. Either add that role to the allowed list, or change the default new-user role to one that’s allowed.
4. Re-test. After enabling the role, have the user try again. No password change is needed — only the role gate was blocking them.

What’s next

• If login now succeeds but the user lands on the wrong content, you’ve moved past authentication into per-role app content — go review that role’s configured screens.
• If codes still aren’t arriving after Step 4, treat it as a notification delivery problem instead, and verify the email/SMS channel end-to-end, independent of login.
• For a deeper picture of how accounts, roles, and the login screen fit together, see the Login app-settings reference (Require Login?, Allow user to sign up with Apple and Google, Require email validation during account setup, Google Login API) and the user-roles overview.