Members cannot sign in

Sign-in that works on the web and fails in the app is nearly always a configuration difference rather than a credential problem.

Which sign-in screen did you place

There are two, and they need different endpoint groups.

Feature	Backed by	Endpoint group
Login	Ultimate Member	Authentication
Default Login	WordPress core	Default Authentication

Placing Default Login and enabling Authentication is a common mismatch, and it fails exactly like a wrong password.

The Ultimate Member login form is not visible to the API

If you placed Login, the Ultimate Member login form needs Show this form to REST API ticked, like any other form. Without it the screen has no fields to render or submit.

See Forms and directories.

Turnstile is half configured

If you enabled Cloudflare Turnstile, both halves of the pair must be present on your site — we store neither:

• The site key is read from your site each time you build, and compiled into that build.
• The secret key stays on your site and verifies the challenge.

With the site key only, the challenge renders and verification fails for everyone. Set both under Memberside → API Keys. See Connection and API keys.

Refused for a challenge that is not on screen

A member is told “Please complete the verification challenge.” on a screen where you switched Turnstile off. The app draws no challenge, so it sends no token, and your site still requires one on that form.

Your site follows each app’s own switch once three things are true:

1. Your site runs Memberside 2.38.0 or later.
2. You saved the app after switching Turnstile off. Until then the builder says Save to apply this to your site.
3. The installed app was built after that update. An older build does not name its app, so your site holds it to Require the challenge.

For apps you cannot rebuild yet, turn Require the challenge off under Memberside → API Keys → Cloudflare Turnstile. A token that is sent is still checked. Apps with Turnstile on keep requiring the challenge once they are rebuilt.

The build fails asking for the Turnstile site key

Builds read the key through the Site → capabilities endpoint, which is opt-in like every other. With it off, the build stops rather than shipping an app that draws no challenge — because your site would still demand a token, and every member would be locked out of sign-in, registration and password reset at once.

Enable the Site group under Memberside → REST API, or switch Turnstile off on the feature.

The same build failure appears when your site holds a secret but no site key. Set the site key, or clear the secret.

Members cannot reset their password

If Turnstile is on for Forgot Password, the challenge fails closed: while Turnstile’s verification service is unreachable, resets stop for everyone. That is deliberate — a challenge that cannot be checked has not passed — but it is the one screen where a locked-out member has no other route.

Clearing the Turnstile secret under Memberside → API Keys switches the challenge off everywhere at once, with no rebuild.

Members can always reset their password on the website itself.

A role allow-list is refusing them

Default Login and Default Register can restrict which WordPress roles may sign in. A member whose role is not listed is refused with valid credentials.

Check the feature’s settings before assuming the account is wrong.

Social sign-in fails only in the built app

It works in the preview and fails on the phone. This is the signing fingerprint.

Native Google sign-in is authorised against your app’s signing certificate. The builder shows the SHA-1 in the social sign-in settings, and it must be registered with your OAuth client.

It changes when the signing certificate changes. See Android signing and the Google setup guide.

A social provider’s button is missing

A provider needs both halves: credentials on your site, and a pick on the feature. Either alone renders nothing, and nothing warns you.

Configured on the site	Picked on the feature	Result
Yes	Yes	The button appears
Yes	No	Nothing
No	Yes	Nothing

See Choosing providers. If no provider at all appears, the Social Login endpoint group is off.

A social sign-in made a second account

The provider returned an email address it does not assert as verified, so matching it to the existing account was refused rather than risked. Microsoft, GitLab, Slack, Amazon and Spotify are all in this position; Reddit and Pinterest return no address at all.

The member signs in by their usual means and links the provider from Social Connects. See Social sign-in.

“Sign in before linking an account” while signed in

Tapping a provider under Social Connects answered this for members who were signed in, on sites running Memberside older than 2.38.0. Update Memberside. No rebuild is needed.

Signed in, but screens still look signed out

The sign-in succeeded and the session is not reaching the screens.

• The Users endpoint group is off. The app cannot read who it is, so every personal screen behaves as though nobody is there.
• The app is an old build pointed at a site whose namespace changed. The plugin moved to memberside/v1 in 2.0.0 with no alias, so apps built against um/v1 cannot authenticate at all. Rebuild and redistribute.

Registration succeeds and the member cannot then sign in

Usually a WordPress-side rule rather than an app one:

• The member’s role requires admin approval before sign-in.
• Email confirmation is required and has not been completed.

Both are Ultimate Member settings, and both behave the same way on the web. Check the account’s status in WordPress.

Related

• Default Login
• Login