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

# Workspace invitations overview

> Pending invites addressed to the current user.

When an admin invites a teammate to a workspace, an `invitation` row is created with the teammate's email and a `pending` status. The teammate can then either accept the invite (which adds them as a member) or decline it.

## Scope

These endpoints are scoped to the **current user's email address**, not to a workspace. They surface invites the signed-in user can act on, regardless of which workspace originally sent them.

The email match is case-insensitive — `Foo@Example.com` and `foo@example.com` resolve to the same set of invites.

## Lifecycle

```mermaid theme={null}
stateDiagram-v2
  [*] --> pending: admin sends invite
  pending --> accepted: user accepts (web UI)
  pending --> rejected: POST /:id/decline
  pending --> canceled: admin cancels
  pending --> accepted: user already a member (decline → accepted)
```

The last transition is unusual: declining an invite to a workspace the user has *already* joined (e.g. via OAuth-driven auto-membership) marks the invite as `accepted` rather than `rejected`, since the membership is the desired end state.

## Accepting invitations

`POST /v1/me/workspace-invitations/{id}/decline` is documented here. **Accepting** invitations is currently handled by the web UI's `auth.api.acceptInvitation` flow (which sets cookies and provisions membership in one round trip) and is not exposed as a public REST endpoint.

## Related guides

* [Workspaces](/api-reference/organizations/overview) — workspace membership and roles.