Member

Overview

The member object identifies a participant in the loyalty program. It is used across endpoints to reference, register, update, or authenticate members using supported identifiers.

When to Use This Object

Include the member object in your request payload when:

• You need to associate an operation with a specific loyalty user
• Identifying a user by phone number, email, or membership key
• Performing lookups, updates, transactions, or benefit calculations

This object is required or optional in the following endpoints:

• /member/register
• /member/update
• /member/details
• /member/shortCode
• /payment
• /transaction
• /event

Supported Identifiers

At least one of the following fields must be included. You can provide more than one to improve accuracy.

Field	Type	Description
membershipKey	string	Internal membership key
commonExtId	string	External/common identifier
shortCode	string	Temporary short code
temporaryToken	string	Temporary JWT token
phoneNumber	string	Member phone number (e.g., "1234567890")
email	string	Member email address
cardNumber	string	Physical card number
customIdentifier	string	Custom business-defined identifier

info

Do not include null or empty strings. Send only valid, populated fields.

Single Identifier Example

{
  "member": {
    "phoneNumber": "1234567890"
  }
}

Member in Transaction Context

This is how the member object is typically used inside a request payload:

{
  "member": {
    "phoneNumber": "1234567890"
  },
  "payment": {
    "action": "pay",
    "amount": 1000
  }
}

Member Response Object

When an endpoint returns a member (for example /member/details), the full member profile is included in the response. The fields below describe that returned object. For a complete payload, see the /member/details response example.

Field	Type	Description
membershipKey	string	Internal membership key
commonExtId	string	External/common identifier
businessId	number	Identifier of the business (tenant) the member belongs to
status	string	Member status (e.g., "active")
firstName	string	Member's first name
lastName	string	Member's last name
phoneNumber	string	Member's phone number
email	string	Member's email address
cardNumber	string	Physical card number
birthday	string	Member's date of birth (ISO 8601)
preferredLanguage	string	Preferred language as an ISO 639-1 two-letter code — the primary language subtag of a BCP 47 tag (e.g. en, es, ca)
gdpr	boolean	GDPR consent accepted
termsOfUse	boolean	Terms of use accepted
allowedSMS	boolean	Consent to receive SMS
allowedEmail	boolean	Consent to receive emails
allowedPush	boolean	Consent to receive push notifications
tags	array	Member-level tags
customFields	object	Business-defined custom key-value pairs
visit	integer	Total number of visits/transactions
totalSpent	number	Cumulative spend amount
points	object	Points balance (see below)
credit	object	Credit balance (see below)
assets	array	Asset objects assigned to the member
behaviors	object	Tracked member behavior data (see below)
regSourceName	string	Source system name the member registered from (from x-source-name at registration)
regSourceType	string	Source type the member registered from (from x-source-type at registration)
registeredAt	string	ISO 8601 timestamp when the member was registered

behaviors Object

Field	Type	Description
favouriteItems	array	Member's favourite items
favouriteBranch	object	Member's favourite branch (see below)
favouriteBranch.branchId	string	Identifier of the branch
favouriteBranch.name	string	Display name of the branch

points / credit Objects

Field	Type	Description
balance	number	Current balance of points or credit
useForPayments	boolean	Whether the balance can be applied toward payments

note

The bulk /members endpoint returns a variant of this object with some renamed fields — for example allowSMS/allowEmail instead of allowedSMS/allowedEmail, pointsBalance/creditBalance (each split into monetary/nonMonetary) instead of points/credit, and createdAt/updatedAt instead of registeredAt. See that endpoint's own response fields for details.

Best Practices

• Always validate phone and email formats before sending
• Avoid sending blank, null, or default placeholders
• Use consistent identifiers across API calls to maintain traceability
• Protect personal identifiers via HTTPS and authorization headers

Related Objects

• newMemberData: Used for profile registration or updates
• transaction: Used to log purchases and track itemized activity
• event: Used to track member-related milestones and external actions
• payment: Used for loyalty redemptions and cancellations