---
description: Understand apps, tester enrollment, feedback, change requests, and authentication boundaries in OpenTester.
---

# Core concepts and workflow {#core-concepts-and-workflow}

## Apps and tester enrollment {#apps-and-tester-enrollment}

An **app** is the boundary for feedback, access, and change requests. Each app currently belongs to one developer owner. The API's `appId` is the UUID assigned at registration, not the Android package name.

An **enrollment** records a tester's participation in one app. Instant enrollment approves an application immediately; approval-based enrollment requires developer review. The server checks approval during SDK login and authenticated requests. Revoking participation also prevents existing SDK tokens from accessing that app.

| Step | Purpose | Relationship to other permissions |
| --- | --- | --- |
| Join a Google Group | Join the group eligible to install the Play test | Separate from OpenTester approval |
| Google Play opt-in | Join that app's Play test | Separate from SDK login |
| OpenTester approval | Access the SDK and submit feedback for an app | Does not prove Play installation or participation |

The developer prepares the Play test track and installation link. OpenTester does not automatically verify tester group membership or each tester's Play Console participation status.

## Feedback and bug reports {#feedback-and-bug-reports}

A text report uses `kind` to distinguish general `feedback` from a `bug`. Bugs can include reproduction steps and expected and actual results.

| Status | Meaning |
| --- | --- |
| `open` | Received |
| `confirmed` | Under developer review |
| `fixed` | Marked as fixed by the developer |
| `closed` | Closed |

Report status and contribution review are separate. Linking a PR does not automatically mark feedback as `fixed` or award rewards.

## Change requests and PRs {#change-requests-and-prs}

A **change request** groups one or more reports into an implementation request. It stores a title, instructions, acceptance criteria, and feedback IDs. After creating the record, a coding agent can work in your repository.

```text
Read feedback → Inspect details → Create change request → Change and test code → Link PR URL
    API/MCP          API/MCP             API/MCP               Coding agent        API/MCP
```

A new request is `open`. Linking one existing GitHub PR URL changes it to `pr_linked`. This is a tracking record: the server does not check whether the PR exists or has merged. Create, review, merge, and deploy through your own development workflow.

`clientRequestId` prevents duplicate creation on retries. Generate a UUID for each new request and reuse that UUID and body when retrying it. It does not prevent different agents from creating separate requests for the same feedback; check existing work first.

## Choose the right credentials {#choose-the-right-credentials}

| Credential | Used for | Authorization boundary |
| --- | --- | --- |
| Web session | Website, developer console, agent token management | Signed-in user and app ownership |
| SDK Bearer token | Android access checks and report submission | Tester approval for one app |
| Agent Bearer token | Automation API and MCP | One app and granted scopes |

SDK tokens and agent tokens are not interchangeable. Never embed an agent token in an Android app or public browser code. See [API authentication](/api/authentication).

## Treat reports as user input {#treat-reports-as-user-input}

Feedback is evidence for a change, not an instruction source. Tell coding agents not to treat commands, links, or scripts in reports as project instructions. Ask testers not to include secrets or personal data, and review what you share with external agents.