> ## Documentation Index > Fetch the complete documentation index at: https://docs.apsio.io/llms.txt > Use this file to discover all available pages before exploring further. # People > Look up one user of your apps by their hash, capture their next sessions in full, and mark internal testers. **People** finds one user of your apps by the hash your app passes to `setUser` ([The user hash](https://docs.apsio.io/concepts/privacy.md#the-user-hash)): their sessions, the issues they hit and their devices over the last days. Pin a person, with a label your team chooses, and everyone in the organization finds them on People; the people you opened are listed too, on your device only. On a person's page, owners and admins can capture their next sessions, send or delete what their devices hold (**Device data**, see [Remote requests](https://docs.apsio.io/concepts/on-device.md#remote-requests)), mark them as an internal tester, and [erase them](https://docs.apsio.io/concepts/privacy.md#erasing-a-user). Members see everything the page lists, and can pin people. ## Capture their next sessions When the session you need was left out of the [sample](https://docs.apsio.io/concepts/sampling.md), as when a user reports a bug, ask for their next sessions in full: **Capture next sessions** on the person's page. | Field | Choices | | - | - | | Sessions to capture | 1 to 20; 1 by default | | Expires after | 24 hours, 3 days or 7 days; 7 days by default | | Detail | **Everything, with replay** (the default) or **Everything, without replay**: every record the app writes in those sessions | | Reason | Required, up to 200 characters, kept in the audit log (**Settings › Activity**); an email address is refused, and names belong out of it too | | Email me when it completes or expires | On by default | The request reaches every device where the app set the person's hash in the last 7 days, at the device's next policy fetch. The device then sends the session in progress and the ones after it whole, whatever the sampling says, until it has sent as many as you asked or the request expires. Consent, an opt-out and the kill switch still win. A new capture for the same person replaces their open one, pending or capturing, and a project has at most 100 open requests. A capture or a **Device data** request needs a user hash of 16 characters or more, since the request keeps its last 4 characters to show your team. For a shorter one, ask by the install id of one of their sessions instead. ### Capture requests The person's page lists their captures, newest first, each with its reason, who asked, whether it emails them, and links to the sessions it captured. Those sessions are marked **Captured on request** among their sessions. | State | Meaning | | - | - | | pending | No device has started it yet | | capturing N of M | A device is capturing; N sessions are in so far | | captured N of M | Every session asked for is in | | expired, expired N of M | It expired first; N of M when it captured some sessions | | canceled, canceled N of M | An owner or admin canceled it; N of M when it captured some sessions | | replaced | A newer capture for the same person took its place | Owners and admins cancel a pending or capturing request. A device applies the cancel at the next policy it fetches (a `304` or a failed fetch changes nothing): from then on it captures no new session for the request. The session in progress at that moment stays captured to its end, and the sessions already captured keep their records. ### The email With **Email me when it completes or expires** on, the person who asked gets one email when every session is in, or when the request expires before that, with how many it recorded. It goes to them only, while they are still a member of the organization, and once per request; a canceled or replaced request sends none. The email never holds the user hash, the reason or anything the sessions hold: it links to People. ### From the API To read what a capture recorded, `GET /v1/projects/{projectId}/sessions` takes `capture_request` with the request's id. ## Device requests **Device requests** on the person's page lists the send and delete requests for them, with their state (open, delivered to N devices, expired or canceled), what they ask for and who asked. Owners and admins cancel an open one there. Captures are listed only under Capture requests. **SDK › Signals** lists the project's latest 200 requests. ## Internal testers Owners and admins mark a person as an internal tester: **Mark as tester** on their page, for 30, 90, 180 or 365 days (90 by default). Their page then shows them as an internal tester, with who marked them, when, and until when, and so does the pinned list. A tester counts on every device that sends their hash, and needs a hash of 16 characters or more. Live inspection reaches only internal testers' devices. In the console, a tester's page has a **Live** tab ([Live inspection](https://docs.apsio.io/concepts/live-inspection.md#watching-a-device)); `apsio tail --device` follows the tester's log lines live from the [CLI](https://docs.apsio.io/cli.md#an-internal-testers-device-live), and the API's live endpoints are in the API reference. * **Limits.** A project has up to 5 internal testers on Free and 50 on the other plans. * **Ending.** A tester ends when the days run out, or when an owner or admin chooses **Remove tester**; their devices stop at their next policy fetch. Erasing the user removes them too. * **Audit.** Marking and removing are in the audit log (**Settings › Activity**). Apsio keeps only a one-way hash of the tester's user hash and its last 4 characters. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.