Resend an invitation

Re-sends the invitation email to a member still in status: "invited" - the previous accept link is superseded. Use when the first email was lost or the link aged out. Scope: team_members:write.

Only meaningful pre-acceptance: any other status → 409 not_invited. Rate limit: 1 resend per member per minute (429).

The member’s id CHANGES after a resend. An invited member’s id is derived from the underlying invitation, and a resend supersedes that invitation, so the id you called this endpoint with stops resolving and GET /v1/team_members/{old_id} returns 404. The 200 response body carries the NEW id: store it, and re-read the member from the list if you have cached the old one. Once the member accepts, their id becomes stable for the life of the account.

POST /v1/team_members/{id}/resend_invitation

Resend an invitation

cURL

curl --request POST \
  --url https://api.vexioncards.one/v1/team_members/{id}/resend_invitation \
  --header 'Authorization: Bearer <token>' \
  --header 'Idempotency-Key: <idempotency-key>'

200

{
  "id": "tm_01HW9R6M4XQ2N8MTX1RVTM0003",
  "object": "team_member",
  "email": "[e-mail]",
  "first_name": null,
  "last_name": null,
  "role": "scanner",
  "location_ids": [
    "loc_01HW9R4P2ZK7N8MTX1RVLOCS02"
  ],
  "status": "invited",
  "origin": "invitation",
  "expires_at": 1759269600,
  "language": "sk",
  "invited_at": 1751700000,
  "activated_at": null,
  "created_at": 1751600000,
  "updated_at": 1751700000
}

Authorizations

Authorization · string · header · required

Your secret API key as a Bearer token: Authorization: Bearer vxn_sk_.... Keys are created and scoped in the dashboard - see Authentication.

Headers

Idempotency-Key · string · required

Required on every mutating POST. 24h byte-replay; 409 idempotency_key_conflict on body mismatch. See Idempotency.

Required string length: 8 - 255

Path Parameters

id · string · required

Team member identifier (tm_ prefix).

Pattern: ^tm_[A-Za-z0-9]+$

Response

200

application/json

Invitation re-sent; invited_at refreshed.

A staff account - dashboard and scanner access. Role lives in the auth provider; the location assignment is dual-written: a queryable mirror in VEXiON (surfaced as Location.team_members[]) plus auth-time enforcement metadata on the user account, which is what locks a scanner to their single store at every request. location_ids here is the ONE write path - both copies sync from it.

id and this resource's identity fields (first_name/last_name/email/language) are anchored to a registry row scoped to YOUR organization - the same person staffing another organization has a DIFFERENT id there, and a PATCH here never changes what that other organization sees for them. Manual transactions carry the acting member as Transaction.team_member_id - which is why revoked and expired members are preserved as records: history stays attributable forever. Members sign in with their email code (OTP) or social login.

id · string · required

Team member identifier, tm_ prefix. For an active member it is stable within your organization across role and location changes, and it is never shared with any other organization they may also staff. For a member still invited it belongs to the current invitation and changes when the invitation is re-sent, when a PATCH edits the invited member's name, role or expires_at (the invitation is re-issued and a new email sent), and when the invite is accepted; the previous id then returns 404. Key invited members by email.

Pattern: ^tm_[A-Za-z0-9]+$

Example:

"tm_01HW9R6M4XQ2N8MTX1RVTM0001"

object · string · required

Always "team_member".

Allowed value: "team_member"

email · string<email> · required

Sign-in email, unique per organization.

Example:

"[e-mail]"

role · enum<string> · required

What they can do:

• admin - everything incl. billing, cards, team; implicit access to ALL locations
• manager - customers, notifications, scanner at assigned locations; no billing, no card editing
• scanner - POS scanner only, at exactly one location (a till account)

Role changes email the member automatically.

Available options: admin, manager, scanner

Example:

"scanner"

location_ids · string[] · required

Assigned locations - the write path for the location↔member relationship (Location.team_members[] is the read mirror). Cardinality is role-bound: admin → always [] (all locations implicit); manager → one or more; scanner → exactly one.

Pattern: ^loc_[A-Za-z0-9]+$

Example:

["loc_01HW9R4P2ZK7N8MTX1RVLOCS01"]

status · enum<string> · required

Lifecycle:

• invited - invitation email sent, account not yet created (invitation origin only)
• active - can sign in and act
• revoked - removed by an admin (DELETE); sessions revoked, record preserved
• expired - expires_at passed; sessions revoked automatically, record preserved

Terminal states (revoked, expired) are not editable - add the person again with a new POST.

Available options: invited, active, revoked, expired

Example:

"active"

origin · enum<string> · required

How the account came to be: invitation - the member accepted an email invite on the branded accept page; direct - an API call created the account, active immediately with email-code (OTP) or social sign-in (typical for till/scanner accounts).

Available options: invitation, direct

Example:

"direct"

created_at · integer · required

Unix seconds.

Example:

1750000000

first_name · string | null

Given name. Null until the member fills their profile (invitation origin) or you supply it (direct origin).

Example:

"Anna"

last_name · string | null

Family name.

Example:

"Kováčová"

expires_at · integer | null

Unix seconds when this member auto-expires - the temporary-staff feature, available on the scanner role only (seasonal hires, one-day events; a till account that cleans itself up). Null = permanent, and always null for admin/manager. At expiry the platform revokes all sessions (signed out within ~5 minutes), removes access, sets status: "expired", and emails the member; a heads-up email goes out 24 h before. Extend or clear by PATCHing before expiry.

Example:

null

language · enum<string> | null

Email language for invitations and lifecycle notices. Defaults to the organization language.

Available options: en, sk, cs, de, null

Example:

"sk"

invited_at · integer | null

When the invitation email was sent. Null for direct origin.

Example:

1750000000

activated_at · integer | null

When the account became active - invitation acceptance time, or creation time for direct origin. Null while invited.

Example:

1750003600

updated_at · integer

Unix seconds of last change.

Example:

1751500000