Answer an invitation

POST/api/v1/mailbox/calendar/invitations/{invitation_id}/rsvp
Requires amailbox token— it acts as one mailbox holder, not as the organization.

Accept, decline or tentatively accept.

The RFC 6638 dance, in order, and the order is what makes it work:

  1. Read the message out of the scheduling inbox.
  2. Set this mailbox's PARTSTAT on it, changing nothing else.
  3. PUT it into the user's own calendar. This is what sends the REPLY -- the scheduling plugin sees an attendee copy whose PARTSTAT changed and generates the iTIP REPLY to the organizer. Nothing here constructs that message by hand.
  4. Remove the message from the scheduling inbox, which is the client's job under RFC 6638. Skipping it leaves the invitation showing as unanswered in every native client forever.

Step 4 is deliberately best-effort: if it fails, the answer has already been sent and recorded, and failing the whole call would invite the user to answer twice.

Parameters

NameInTypeDescription
invitation_idrequiredpathstring

Request body

Request

POST/api/v1/mailbox/calendar/invitations/{invitation_id}/rsvp
curl -X POST 'https://app.mailyte.com/api/v1/mailbox/calendar/invitations/01JBT8XQ2M9WYC3K4F6R7S8T9V/rsvp' \
  -H 'Authorization: Bearer MAILBOX_TOKEN'
The key names its own organization, so no X-Organization-ID header is needed.

Response

Successful Response

Returned inside the standard envelope.

Errors

StatusWhen
422Validation Error

Every status, with what causes it and what to do, is on the error reference.