Skip to content

Tester portal ​

The tester portal at /t is a small browser interface for private builds. It uses its own email sign-in cookie, separate from GitHub dashboard sessions and API tokens. A tester must belong to a group with a distribution for a release before that release appears in the portal.

Sign in ​

Method and pathResult
GET /t/loginHTML email form
POST /t/loginHTML confirmation page; email link queued for a registered tester
GET /t/auth/:tokenHTML page with a Continue button
POST /t/auth/:tokenConsumes the link, sets a tester session cookie, redirects
POST /t/logoutClears the session and redirects to sign-in

To sign in, open /t/login, enter the email address registered by an organization, and follow the emailed link. The portal shows the same “check your email” response even for an address that is not registered. A link requested from the sign-in form expires after 15 minutes. An invitation sent by a release manager from the tester API lasts seven days.

Opening an emailed link with GET /t/auth/:token only shows a confirmation button. The link is consumed by the following POST, so email scanners that preview links do not use them up. Each link works once. A successful sign-in sets the HttpOnly rd_tester cookie, scoped to /t, for up to 30 days. Signing out deletes that session on the server. If a tester opens a build URL while signed out, the portal sends them to sign-in and returns them to the build after authentication.

Find and download builds ​

GET /t lists the latest shared builds for the signed-in email address. A release appears once even if several of the tester's groups received it. The portal checks group membership each time, so withdrawing a distribution or removing a tester from a group can remove access to a build. Revoked releases do not appear. The list is limited to the latest 200 distribution records before duplicate releases are removed; it is not a complete historical archive.

GET /t/builds/:releaseId shows the build's app name, version, build number, artifacts, SHA-256 checksums, release notes, and any “what to test” text. It returns a 404 page when the release does not exist, has been revoked, or has not been shared with one of the tester's groups. When several groups share the same release, the portal displays the most recently created nonempty “what to test” text it finds.

The page creates signed artifact links that expire after 15 minutes. Reload the page for fresh links if a download has expired. For an IPA on an HTTPS instance, the portal offers an iOS install link through an OTA manifest. Other artifacts use /dl/:artifactId with the expiring signature. A download may redirect to backing storage, so clients should follow redirects.

The portal serves HTML and redirects; it is not a JSON management API. To register testers and groups, use Testers and groups. To share a release, use Build distribution.

Send feedback ​

The build page includes a feedback form and lists the signed-in tester's own earlier feedback for that build. Fields are kind (bug, suggestion or other), message (up to 5,000 characters), and optional app version and device (up to 200 characters each). The version and device are prefilled from the browser's user agent and stay editable. The form works without JavaScript.

POST /t/builds/:releaseId/feedback accepts multipart/form-data with the fields above and up to 5 screenshots files, each at most 5 MiB. On success it redirects back to the build page with a notice. The same access rules as the build page apply, so an inaccessible release returns the same 404 page. Each tester cookie is limited to 10 submissions per hour.

Only PNG, JPEG and WebP are accepted. The server identifies the type from the file's leading bytes and ignores the client's Content-Type and filename; SVG and other formats are rejected. Original image bytes are stored unchanged, including any EXIF metadata, and the form warns that screenshots are visible to the team. GET /t/feedback/:attachmentId serves a tester's own attachment only; there are no public or signed attachment URLs.

Feedback is kept when a tester record is removed, with the tester's email retained. Deleting a release, app or organization deletes its feedback and screenshot files.