Stay organized with collections
Save and categorize content based on your preferences.
Registering test phone numbers
This document shows you how to register phone numbers with Identity Platform
for development purposes. This allows you to test authentication methods that
involve sending an SMS message, such as phone sign-in and multi-factor
authentication.
Using a test number (rather than a real number you own) has several benefits:
It integrates seamlessly with the iOS and Android emulators.
It eliminates the overhead of sending an actual SMS.
You can execute consecutive tests with the same phone number without being
throttled.
You can write integration tests without being blocked by security checks.
It doesn't consume your usage quota.
You can register up to 10 phone numbers for development.
If you are testing phone authentication, locate it in the list of providers,
then click the Edit icon. If you are testing multi-factor
authentication, select the Multi-factor SMS tab, then click Edit.
Under Phone numbers for testing, enter a phone number and verification
code to register.
The phone number should use
E.164 format, and cannot already be assigned to an existing
Identity Platform user. The verification code should be six digits.
For security purposes, choose numbers that are difficult to guess, and avoid
obvious patterns like +1 123-456-7890.
Click Save.
Testing phone numbers are treated like real phone numbers by
Identity Platform, so store them securely and rotate them at regular
intervals.
Manual testing
You can immediately begin using test phone numbers in your app, either directly
or using the iOS and Android emulators. When signing in with a test phone
number, no SMS verification code is sent; instead, enter the code you registered
when creating the test number.
After signing in, an Identity Platform user is created using the test phone
number. This user has the same behavior and properties as a real user,
including a valid ID token, meaning it can access all your apps and services.
To restrict access from your test users, consider creating a test role with
limited permissions and assigning it using
custom claims.
Integration testing
In addition to manual testing, the client SDK contains APIs that can help
write integration tests. These APIs disable the reCAPTCHA and app verification
requirements, making them easier bypass with automation.
The following example shows how to test signing in a user with a phone number:
JavaScript
// Turn off phone app verification.firebase.auth().settings.appVerificationDisabledForTesting=true;varphoneNumber="+16505554567";vartestVerificationCode="123456";// Render a fake reCAPTCHA and resolve without app verification.varappVerifier=newfirebase.auth.RecaptchaVerifier('recaptcha-container');// signInWithPhoneNumber will call appVerifier.verify(), which will resolve// with a fake reCAPTCHA response.firebase.auth().signInWithPhoneNumber(phoneNumber,appVerifier).then(function(confirmationResult){// confirmationResult can resolve using testVerificationCode.returnconfirmationResult.confirm(testVerificationCode)}).catch(function(error){// Error; SMS not sent// ...});
Visible and invisible mock reCAPTCHA verifiers behave differently when
app verification is disabled:
Visible reCAPTCHA: To simulate a user click, the reCAPTCHA will resolve
itself automatically after a brief delay.
Invisible reCAPTCHA: To simulate app verification, the reCAPTCHA will
resolve automatically when appVerifier.verify() is called.
Mock reCAPTCHAs will still trigger their callbacks when they resolve or expire.
What's next
Add multi-factor authentication to your
web,
iOS, or
Android app.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[[["\u003cp\u003eThis guide details how to register up to 10 test phone numbers with Identity Platform for development and testing, allowing you to simulate phone-based authentication methods.\u003c/p\u003e\n"],["\u003cp\u003eUsing test numbers eliminates the need for real SMS messages, prevents throttling, bypasses security checks, and doesn't affect your usage quota.\u003c/p\u003e\n"],["\u003cp\u003eTo register, navigate to the Identity Providers page in the Google Cloud console, input a phone number in E.164 format and a six-digit verification code under "Phone numbers for testing," ensuring the number isn't already in use by an existing Identity Platform user.\u003c/p\u003e\n"],["\u003cp\u003eTest phone numbers function like real numbers within Identity Platform, allowing you to use them directly or with iOS/Android emulators and requiring the registered verification code for sign-in.\u003c/p\u003e\n"],["\u003cp\u003eClient SDK APIs are available to simplify integration testing by disabling reCAPTCHA and app verification, demonstrated with a JavaScript example that also showcases mock reCAPTCHA behavior.\u003c/p\u003e\n"]]],[],null,["# Registering test phone numbers\n==============================\n\nThis document shows you how to register phone numbers with Identity Platform\nfor development purposes. This allows you to test authentication methods that\ninvolve sending an SMS message, such as phone sign-in and multi-factor\nauthentication.\n\nUsing a test number (rather than a real number you own) has several benefits:\n\n- It integrates seamlessly with the iOS and Android emulators.\n- It eliminates the overhead of sending an actual SMS.\n- You can execute consecutive tests with the same phone number without being throttled.\n- You can write integration tests without being blocked by security checks.\n- It doesn't consume your usage quota.\n\nYou can register up to 10 phone numbers for development.\n\nRegistering a test phone number\n-------------------------------\n\nTo register a test phone number:\n\n1. Go to the **Identity Providers** page in the Google Cloud console. \n\n [Go to the Identity Providers page](https://console.cloud.google.com/customer-identity/providers) \n\n2. If you are testing phone authentication, locate it in the list of providers,\n then click the **Edit** icon. If you are testing multi-factor\n authentication, select the **Multi-factor SMS** tab, then click **Edit**.\n\n3. Under **Phone numbers for testing**, enter a phone number and verification\n code to register.\n\n The phone number should use\n [E.164 format](https://wikipedia.org/wiki/E.164), and cannot already be assigned to an existing\n Identity Platform user. The verification code should be six digits.\n For security purposes, choose numbers that are difficult to guess, and avoid\n obvious patterns like `+1 123-456-7890`.\n4. Click **Save**.\n\nTesting phone numbers are treated like real phone numbers by\nIdentity Platform, so store them securely and rotate them at regular\nintervals.\n\nManual testing\n--------------\n\nYou can immediately begin using test phone numbers in your app, either directly\nor using the iOS and Android emulators. When signing in with a test phone\nnumber, no SMS verification code is sent; instead, enter the code you registered\nwhen creating the test number.\n\nAfter signing in, an Identity Platform user is created using the test phone\nnumber. This user has the same behavior and properties as a real user,\nincluding a valid ID token, meaning it can access all your apps and services.\n\nTo restrict access from your test users, consider creating a test role with\nlimited permissions and assigning it using\n[custom claims](/identity-platform/docs/how-to-configure-custom-claims).\n\nIntegration testing\n-------------------\n\nIn addition to manual testing, the client SDK contains APIs that can help\nwrite integration tests. These APIs disable the reCAPTCHA and app verification\nrequirements, making them easier bypass with automation.\n\nThe following example shows how to test signing in a user with a phone number: \n\n### JavaScript\n\n // Turn off phone app verification.\n firebase.auth().settings.appVerificationDisabledForTesting = true;\n\n var phoneNumber = \"+16505554567\";\n var testVerificationCode = \"123456\";\n\n // Render a fake reCAPTCHA and resolve without app verification.\n var appVerifier = new firebase.auth.RecaptchaVerifier('recaptcha-container');\n // signInWithPhoneNumber will call appVerifier.verify(), which will resolve\n // with a fake reCAPTCHA response.\n firebase.auth().signInWithPhoneNumber(phoneNumber, appVerifier)\n .then(function (confirmationResult) {\n // confirmationResult can resolve using testVerificationCode.\n return confirmationResult.confirm(testVerificationCode)\n }).catch(function (error) {\n // Error; SMS not sent\n // ...\n });\n\nVisible and invisible mock reCAPTCHA verifiers behave differently when\napp verification is disabled:\n\n- **Visible reCAPTCHA:** To simulate a user click, the reCAPTCHA will resolve\n itself automatically after a brief delay.\n\n- **Invisible reCAPTCHA** : To simulate app verification, the reCAPTCHA will\n resolve automatically when `appVerifier.verify()` is called.\n\nMock reCAPTCHAs will still trigger their callbacks when they resolve or expire.\n\nWhat's next\n-----------\n\n- Add multi-factor authentication to your [web](/identity-platform/docs/web/mfa), [iOS](/identity-platform/docs/ios/mfa), or [Android](/identity-platform/docs/android/mfa) app."]]