Update a team member

Edits an invited or active member. Scope: team_members:write.

• Role changes email the member and re-apply the location cardinality rules - demoting to scanner while multiple locations are assigned requires location_ids (exactly one) in the same request (422 scanner_requires_single_location)
• location_ids is SET semantics and the single write path - VEXiON’s location mirror AND the member’s auth-time enforcement metadata both sync from it
• expires_at (scanner only) extends, shortens, or clears the auto-expiry - the way to give a temp another month, or make them permanent (null)
• Terminal states are immutable: PATCHing a revoked or expired member → 409 member_not_editable; add the person again with POST
• Email address is identity - not changeable via API
• Revoking a member is dashboard-only - there is no DELETE on this API
• Delegated billing: dashboard only

PATCH /v1/team_members/{id}

cURL

Extend a temp

curl --request PATCH \
  --url https://api.vexioncards.one/v1/team_members/{id} \
  --header 'Authorization: Bearer <token>' \
  --header 'Content-Type: application/json' \
  --data '
{
  "expires_at": 1761955200
}
'

200

Updated

{
  "id": "tm_01HW9R6M4XQ2N8MTX1RVTM0001",
  "object": "team_member",
  "email": "[e-mail]",
  "first_name": "Anna",
  "last_name": "Kováčová",
  "role": "scanner",
  "location_ids": [
    "loc_01HW9R4P2ZK7N8MTX1RVLOCS01"
  ],
  "status": "active",
  "origin": "direct",
  "expires_at": 1761955200,
  "language": "sk",
  "invited_at": null,
  "activated_at": 1750000000,
  "created_at": 1750000000,
  "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

Recommended on PATCH and DELETE for safe retries.

Path Parameters

id · string · required

Team member identifier (tm_ prefix).

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

Body

application/json

Partial update of an invited or active member - terminal states (revoked, expired) return 409 member_not_editable.

Role and locations move together: changing role to scanner while the member has multiple locations requires location_ids (exactly one) in the same request. Delegated billing is never configurable via API - dashboard only.

first_name · string

New given name.

Maximum string length: 100

last_name · string

New family name.

Maximum string length: 100

role · enum<string>

New role. The member is emailed about the change. Cardinality rules re-apply - pair with location_ids when the current assignment would violate them.

Available options: admin, manager, scanner

location_ids · string[]

SET semantics - the full assignment after the update. Same role-bound cardinality as on create.

Maximum array length: 100

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

expires_at · integer | null

Extend, shorten, or clear (null) the auto-expiry - scanner role only (422 expires_at_scanner_only). Must be in the future (422 expires_at_in_past).

Response

200

application/json

Updated member (full object).

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