AuralisDocs
OperationsInvitations

Send an invitation again with a fresh link

Mint a fresh token, invalidate the previous one, reset the expiry (FR-95).

/v1/workspace/invitations/{invitation_id}/resendAdmin
Operation id
resend_invitation
Access
An editor or a viewer is refused.
POST/v1/workspace/invitations/{invitation_id}/resend

Mint a fresh token, invalidate the previous one, reset the expiry (FR-95).

Use this when the email did not arrive or the link has run out. The previous link stops working the moment this succeeds, so anyone still holding the old email has to use the new one.

The role and the address are unchanged. The expiry restarts from now, and delivery.attempts keeps counting across every send this invitation has ever cost rather than restarting.

An expired invitation can be resent, and this is the remedy for one. An accepted or revoked invitation cannot: that is refused with 409 invitation_not_pending, and the refusal carries the state it is actually in. Resending is rate limited per workspace on the same budget as issuing.

Overwriting token_hash is the invalidation. There is no second copy of the old digest anywhere, so the previous link stops matching in the same statement that makes the new one work. AC-104 asserts exactly that pair.

An expired invitation is resendable and that is the remedy for one; an accepted or revoked one is not, and each says so with its own answer. The predicate is the partial index's, so what may be resent and what holds the pending slot are one rule.

Charged against the same issuance budget, because a resend is an issuance: it rotates the token and sends a message. Counting only the first would leave the send path unbounded behind the one button whose entire purpose is to send again.

Tenancy: the request is scoped to one workspace, and the credential presented is what selects it. A caller with no membership in that workspace is refused with 404, which is indistinguishable from a workspace that does not exist.

Authorisation: admin or owner. An editor or viewer receives 403 insufficient_role.

Access: Authorization: Bearer carrying either a realm access token or an API key. A key must hold the invitations:write scope, and the workspace role of the person who owns it must meet the floor above.

Authorization

AuthorizationBearer <token>

A realm-issued access token, presented as Authorization: Bearer <token>. It acts as the person who signed in, and every operation resolves their workspace role live from the membership record.

In: header

Path Parameters

invitation_id*Invitation Id
Formatuuid

Response Body

application/json

application/json

curl -X POST "https://example.com/v1/workspace/invitations/497f6eca-6276-4993-bfeb-53cbbbba6f08/resend"
{  "id": "3a9c7e12-58bd-4f06-9a44-2c7e1b0d8f31",  "email": "sam.okafor@northwind.example",  "role": "editor",  "state": "pending",  "expires_at": "2026-08-22T09:12:00+00:00",  "created_at": "2026-08-14T10:04:00+00:00",  "invited_by": {    "id": "c0f4a7d3-1b62-4e58-8d90-6f3a2c5e7b18",    "display_name": "Dana Osei",    "email": "dana.osei@northwind.example"  },  "delivery": {    "state": "sent",    "attempts": 2,    "message_id": "0100019180a4c1f2-9f0a4a2e-1e4c-4d31-9a77-5b8c2d1e0f44-000000",    "last_sent_at": "2026-08-15T09:12:01+00:00"  }}