Meta Rejection: Test Credentials Do Not Work — Expert Diagnosis

When Meta App Review returns The test credentials that you provided do not work, the review never reached your use case. Reviewers could not log in with the credentials in App Verification Details — so permission proof and screencast recreateability never got a fair test. This article covers Meta’s Rejection Guide wording, why Meta Test Users differ from real Facebook accounts (and why 2FA locks kill submissions), how this differs from Unable to Verify Use Case, Inadequate Demonstration, and unable to verify permissions requested while testing, and why password swaps without diagnosis often burn a 7-day cooldown.

What this rejection actually means

Meta’s App Review Rejection Guide is explicit: apps that do not rely on Facebook Login for authentication must include login credentials for a test account reviewers can use. If they cannot log in with those credentials, the submission is rejected with “The test credentials that you provided do not work.”

The same outcome appears when teams need a Facebook identity for OAuth or Business Login, but ship a real personal login, 2FA-locked founder account, expired password, or internal-only staging user. The reviewer never enters the product — everything after login is invisible.

Reviewer psychology: no login, no review

App Review is not a white-glove onboarding call. Reviewers will not wait for OTPs, device approvals, or invented recovery flows. Incorrect password, checkpoint, CAPTCHA, geo friction, or “confirm it’s you” ends the submission.

That is why a use case can “look valid” and still fail on credentials — testing never starts. Ambiguity defaults to rejection. Pasting a Gmail recovery path into notes is fragile; Meta’s remediation centers on a test user you verified externally, not third-party mailboxes.

Technical nuances: Meta Test User vs real credentials and 2FA

Across hundreds of Meta apps, the same credential failure modes appear under this label:

• Real Facebook account instead of a Meta Test User — Platform Policy restricts fake accounts for app management. Meta’s guide: do not create a new Facebook user as a “test user”; if a Facebook identity is required, create a Facebook Test User.
• 2FA / checkpoint locks — founder or shared real accounts with two-factor auth, login alerts, or device confirmation block unfamiliar reviewer locations.
• Credentials never verified externally — works on VPN/allowlisted IP, fails outside the internal network. Meta asks you to verify sign-in externally before resubmitting.
• Wrong identity layer — product email/password and Facebook OAuth both required, but only one layer was provided.
• Stale or rotated secrets — password changed after the screencast, or Test User reset without updating App Verification Details.
• Server-to-server (S2S) mishandled — when login credentials cannot be supplied, Meta expects a clear description of how the app uses data from each requested permission/feature (see S2S sample guidance) — not an empty field.

Official remediation: finish development; create a test user and verify external sign-in; include credentials in App Verification Details; resubmit. When a Facebook identity is required, that means a Facebook Test User — not a fabricated personal profile.

Policy grounding: trustworthy access, not fake accounts

Under Meta Developer Policies section 1. Build a trustworthy product, developers must follow Developer Docs instructions, including Platform allowed usage. Credential failures sit upstream: reviewers cannot evaluate trustworthy Platform use if they cannot enter the app.

Meta’s Rejection Guide also warns against creating new Facebook user accounts as test users — Platform Policy restricts fake accounts for app management. A Meta-provisioned Test User (when a Facebook identity is needed) is the compliant path; a 2FA-locked personal login is fragile and strategically wrong.

Official references worth reading before you rotate another password:

• Meta App Review Rejection Guide — “The test credentials that you provided do not work”
• Meta Developer Policies — Build a trustworthy product

Expert Diagnosis framework (not a DIY paste template)

Every app’s auth stack is unique: some need product email login only; some need Facebook Login; some need both plus Business assets. A full copy-paste “credentials block” would either mislead your team or violate policy. Specialists diagnose first:

If login works but permissions fail after entry, see unable to verify permissions requested while testing. If the video is weak, see Inadequate Demonstration. Managed help: Facebook App Review service and case studies.

What not to do after this rejection

• Do not create a fake personal Facebook account to “act as” a test user — Meta’s guide forbids that pattern under Platform Policy.
• Do not hand reviewers a 2FA-protected founder login and hope they can clear checkpoints.
• Do not resubmit without verifying the exact credentials from outside your internal network.
• Do not assume a working screencast login substitutes for credentials printed in App Verification Details.

Provision the right test identity. Verify it externally. Document it clearly. Then submit once. Anything else is gambling with cooldown risk.