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.
/v1/workspace/invitations/{invitation_id}/resendMint 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.
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
uuidResponse 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" }}