# Meeting RSVP

The participation status shows whether an employee has accepted an invitation to a calendar meeting, declined it, or has not responded yet. The methods in this section read and change only the status of the employee the request runs as.

Bitrix24 API: `calendar.meeting.status.get`, `calendar.meeting.status.set`
Scope: `calendar`

## Operations

- [Get meeting participation status](./meeting-status-list.md) — `GET /v1/calendar-events/:id/meeting-status`
- [Change meeting participation status](./meeting-status-set.md) — `PUT /v1/calendar-events/:id/meeting-status`

## Status values

The status is returned in the `status` field, and the same field carries it on write. In the event's `attendeeList` field, the same response is recorded as a letter code.

| `status` | Meaning | In `attendeeList` | Writable |
|----------|------------|------------------|:--------------:|
| `invited` | Invited, has not responded yet | `Q` | yes |
| `accepted` | Accepted the invitation | `Y` | yes |
| `declined` | Declined the invitation | `N` | yes |
| `host` | Meeting organizer | `H` | no |

## What to know before you start

1. **Only your own status.** The request runs as the owner of the personal key or as the employee whose session token is passed in the `Authorization` header. The other attendees' responses are returned in the event's `attendeeList` field — [`GET /v1/calendar-events/:id`](/docs/entities/calendar-events/get).
2. **Any copy of the meeting works.** An invitee has their own copy of the meeting in their calendar, with a separate `id`. The copy's `parentId` field points to the organizer's event. The methods accept both `id` values and return the same status.
3. **Only meetings the employee participates in.** For an event whose `isMeeting` is `false`, and for a meeting the employee was not invited to, the response is `422 BITRIX_ERROR`. In these cases the status does not change.
4. **The organizer's status cannot be changed.** For the organizer, a read returns `host`, a write returns `422 BITRIX_ERROR`, and the status stays unchanged.

## Typical scenario

1. Find the meeting in the employee's calendar: [`GET /v1/calendar-events?type=user&ownerId=:userId`](/docs/entities/calendar-events/list); the employee ID comes from [`GET /v1/users`](/docs/entities/users/list). A meeting has `isMeeting` equal to `true`.
2. Read your own response: [`GET /v1/calendar-events/:id/meeting-status`](./meeting-status-list.md).
3. Accept or decline the invitation: [`PUT /v1/calendar-events/:id/meeting-status`](./meeting-status-set.md) with the `status` field.
4. Check the other attendees' responses: the `attendeeList` field in [`GET /v1/calendar-events/:id`](/docs/entities/calendar-events/get).

## See also

- [Calendar events](/docs/entities/calendar-events)
- [Get event](/docs/entities/calendar-events/get)
- [Calendar](/docs/calendar)
