> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orriven.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Attendees

> The registrations list, adding attendees from the console, approval and waitlist statuses, and the attendee detail page.

The **Attendees** page lists everyone registered for the event. Each row is a **registration** — one person in one event — with their name, email, ticket type, status and when they registered. The registration is the thing everything else attaches to: form answers, perks, hotel stays, activity history.

## Registration statuses

| Status               | Meaning                                                                                        |
| -------------------- | ---------------------------------------------------------------------------------------------- |
| **Pending approval** | The ticket type requires approval and an organizer has not decided yet.                        |
| **Confirmed**        | Registered and counted. This is the status that consumes ticket-type capacity.                 |
| **Waitlisted**       | The ticket type was full and its waitlist is on; the person holds a place in line, not a seat. |
| **Cancelled**        | The registration was cancelled. The record stays; the seat is released.                        |
| **Rejected**         | An organizer declined the application.                                                         |

## Add an attendee from the console

Not everyone arrives through the public page — speakers, VIPs and staff are often keyed in directly.

<Steps>
  <Step title="Click Add attendee">
    Enter the person's name and email, and pick a ticket type if the event uses them.
  </Step>

  <Step title="They are registered immediately">
    A console-added registration is confirmed on the spot. **No order is involved** — a registration never requires one; checkout is just how the public page happens to create registrations.
  </Step>
</Steps>

<Note>
  If that email is already registered, the console tells you so instead of creating a duplicate — one person holds one registration per event.
</Note>

## Approving and rejecting

When a ticket type has **requires approval** switched on, public registrations land as **Pending approval** and wait for a decision:

* **Approve** confirms the place.
* **Reject** declines it. The reason you record is internal — the applicant never sees it — and rejecting releases any redemption-code use the application consumed.

While approval is on, capacity is a **soft** limit: you decide who gets in, not the counter. The detail page shows who decided and when.

## The attendee detail page

Click **Details** on any row to open the person's full record:

<AccordionGroup>
  <Accordion title="Registration">
    Status, ticket type, redemption code used, registration time — and the approve/reject controls when the application is pending. **Edit info** changes the person's name or email.
  </Accordion>

  <Accordion title="Form responses">
    What the person answered on the [registration form](/en/ticketing/registration-form), exactly as submitted. Alongside it, the submission capture: what the platform observed when the form was submitted.
  </Accordion>

  <Accordion title="Perks">
    Everything this person holds — perks that came with their ticket type, plus any **granted directly** to this one registration. Direct grants are edited here; see [Perks](/en/ticketing/perks).
  </Accordion>

  <Accordion title="Housing">
    Shown once the [Housing module](/en/housing/overview) is enabled for the event: this person's hotel stays — hotel, room type, nights and status — with a shortcut to the [Stays](/en/housing/stays) page.
  </Accordion>

  <Accordion title="Activity">
    A timeline of every change to this registration — who did it, what changed, and how long after registering. Registrations from the public page, console edits, approvals, and every housing change all appear here.
  </Accordion>
</AccordionGroup>

## Rules to know

* A registration is the atom: it exists whether the person came through the public page or was keyed in, and it stays open until the event ends.
* Console-added attendees need no order and are confirmed immediately.
* Only **confirmed** registrations count against a ticket type's capacity; approval mode makes that capacity soft.
* Rejection reasons are internal only.
* Cancelling releases the seat (and any redemption-code use) but keeps the record — the list is history as well as state.
* Everything on this page works today with free ticketing; paid ticketing is coming and changes none of it.