Self sign up links for beta testers: invite links, domain rules, no forced sign in

Adding beta testers one email at a time works for five people. It does not work for a QA vendor with thirty staff, a client who wants their whole support team on the beta, or a community of early users. At that point you want a self sign up link: one URL you post somewhere, and testers add themselves.

A good invite link is more than a URL. It has to decide who may join, how you know their email is real, where they land, and how to stop it when it leaks. This guide compares the options teams use in 2026, then goes through the design choices and how AppForShare join links handle them. Firebase facts come from its documentation as read on November 2, 2026.

The options for self sign up

Option	Platforms	What the tester needs	Who it suits
TestFlight public link	iOS	An Apple ID and the TestFlight app; builds pass Apple's beta review for external testers	Public iOS betas
Google Play open or closed testing	Android	A Google account and the Play Store	Android betas close to release
Firebase App Distribution invite link	iOS and Android	A Google account; App Tester on Android, the Firebase profile on iPhone	Teams already on Firebase and Google accounts
AppForShare join link	iOS and Android	An email address they can open	Clients, vendors and testers outside your company

The store options are the right choice for big public betas. They are also tied to store accounts and, on iOS, to review. The other two are for builds you share before that point.

How Firebase invite links work

Firebase describes an invite link as "a unique URL that lets testers enter their email addresses to sign up to test an app" (create invite links). You make one in the Invite links tab of App Distribution. There are two kinds:

• A link to an app, with no group. Testers are added only to the latest distributed release of that app.
• A link to a group. Testers are added to all releases, across all apps, that the group has access to.

Separately, the "Restrict invitation acceptance to recipient's email" toggle in the Testers and Groups tab makes testers accept with the Google account of the address they were invited at. It is off by default. Firebase notes that "if account restrictions are enabled, invite links require that domain restrictions are also enabled."

After signing up, the tester follows the normal Firebase tester flow, which starts with "sign in with Google and accept the invitation" (tester setup). The tester limits still apply: 500 per project and 200 per group, with a no-cost increase on request (add and remove testers).

For teams on Google Workspace this works well. The friction is the same as for email invitations: a tester without a Google account has to make one, and a tester on a restricted company account can hit a 403 "Contact your admin for access" error. More on that in Firebase App Distribution without a Google account.

Six decisions for any invite link

1. Confirm the email, or not

A link that accepts any typed address lets someone sign up as anyone. The usual fix is a confirmation email: the tester types an address and proves it by opening a link sent there. A sign in with a big provider does the same job, at the cost of requiring that account.

2. Limit by email domain

For a client or a vendor, a domain rule is the simplest safeguard. A link that only accepts @client.com can be posted in the client's chat without worrying where it travels next. Decide whether subdomains such as qa.client.com count.

3. Cap the number of joins

A cap turns a leak into a small problem. If you expect 30 vendor testers, a cap of 35 means a forwarded link stops working once the team is in.

4. Pause and replace

You need to stop a link without deleting everyone who joined through it, and to issue a new address if the old one is posted publicly. Removing a link should not remove its testers.

5. Decide where testers land

A link should put testers straight into the right place, usually a group that has the right projects. One link per audience (client, vendor, internal) keeps access easy to change later.

6. Do not reveal who already tests

A sign up page that says "you are already a tester" tells anyone with the link which addresses are on your list. Answer the same way for new and existing addresses, and handle the difference in the email.

A short playbook

1. Make one link per audience, each tied to a group.
2. Put a domain rule on client and vendor links. Leave it off only for links you share one to one.
3. Set a cap a little above the number of people you expect.
4. Post the link where only that audience can see it.
5. When the group is in, pause the link. Turn it back on for the next wave.
6. If the link leaks, make a new address and pause or delete the old one. Testers who joined stay.

How AppForShare join links work

Join links are part of the Team plan and are made for private projects, where only invited testers can open builds. Each project can have up to 10 links. You make them on the project's Testing page.

What the tester does

1. Opens appforshare.io/join/<token> on any device. The page shows the app and who shares it.
2. Enters an email address, and a name if they like.
3. Opens the confirmation email and taps the link. It is valid for 24 hours.
4. Lands on the install page of the newest build of the project. From then on the tester gets new build emails like any invited tester.

There is no password, no Google account and no app to install first. The confirmation emails go out in the tester's language when it is one of the seven install page languages.

What you control

• Group. A link can add testers to the project directly or to a tester group, which gives them every project of that group.
• Email domains. Up to 20 domains per link. A domain also accepts its subdomains, so acme.com takes qa.acme.com. A refused address gets a plain message naming the allowed domains.
• Join cap. When the cap is reached, the page says the link has reached its tester limit. Two confirmations at the same moment cannot pass the cap.
• Pause. A paused link takes no one and says so. Pausing works on any plan; turning a link back on needs Team.
• New address. Replaces the token, so the old URL stops working. Deleting a link keeps everyone who joined.

The page gives the same answer whether or not an address already tests the app, and each join is recorded in the workspace activity feed with the tester's name or email. On Team, the project's tester list shows each tester's status: invited, opened the link, on an older build or on the newest build.

What it does not do

• It does not register iPhones. Ad Hoc builds still need each UDID in the profile. Pair the join link with the iOS onboarding link, which collects the UDID, or with device registration.
• It is not a public beta tool for thousands of strangers. For that, TestFlight public links and Play testing tracks are built for the job, and a channel can send iPhones to a TestFlight link while Android gets the APK.

More detail is on the tester join links page. Groups are covered under tester groups, and plan prices are on pricing. For scripts, the CLI also manages testers and groups (appforshare testers add, appforshare groups add, Team).

Common questions

Is a self sign up link safe for a client beta?

With a domain rule, an email confirmation and a cap, a forwarded link does little harm: outsiders cannot confirm an address at the client's domain, and the cap stops a flood. Pause it once the team is in.

Do testers need an account to join?

On AppForShare, no. They confirm an email address. On Firebase App Distribution, testers sign in with a Google account to accept. On TestFlight they use an Apple ID, and on Play testing a Google account.

What happens to testers if I delete the link?

They keep their access. Deleting or pausing a link only stops new sign ups.

Can one link give access to several apps?

Yes, if it adds testers to a group that has those projects. Firebase group links work the same way.