CrmCustomerDto reference
This is for developers working with ReceiptRoller's customer (CRM) data via the API, MCP, or Webhook. It explains how customer information imported from a POS is normalized.
CrmCustomerDto is the canonical model for ReceiptRoller's customer master. Customers registered as members in the app, customers imported from a POS (Smaregi / Square) member master, and customers registered manually from the store CRM screen — all of them are consolidated into this single type.
One business account = one CRM namespace. Customers can be shared across multiple stores under the same business account, and the StoreIds field expresses "which store(s) they belong to."
Main fields
Identifiers
| Field | Type | Description |
|---|---|---|
OrganizationId | string | Business account ID. PartitionKey. |
CustomerId | string | RR internal customer ID (GUID). RowKey. |
StoreIds | string | Comma-separated list of the store IDs the customer belongs to. Readable and writable as an array via the StoreIdList property. |
Name and contact
| Field | Type | Description |
|---|---|---|
LastName / FirstName | string | Last and first name (kanji). Has a FullName property for display. |
LastNameKana / FirstNameKana | string | Last and first name (kana). Has a FullNameKana property. |
Email | string | Email address. Normalized by lowercasing and trimming whitespace. One of the matching keys. |
Phone | string | Phone number. Normalized to E.164 format (e.g. +819012345678). One of the matching keys. |
Gender | string | Gender. Optional. |
DateOfBirth | DateTime? | Date of birth. Optional. Stored as UTC. |
Address
PostalCode / Prefecture / City / Address1 / Address2. Concatenated for display via the FullAddress property. All string and optional.
Membership information
| Field | Type | Description |
|---|---|---|
MembershipCode | string | Membership number. Auto-assigned by RR, or imported from the POS (Smaregi's customerCode, Square's reference_id, etc.). One of the matching keys. |
MembershipLevel | string | Membership rank. Default "Standard". E.g. Standard / Silver / Gold. |
Behavioral metrics
| Field | Type | Description |
|---|---|---|
VisitCount | int | Number of visits. Automatically aggregated from POS transactions. |
TotalSpent | decimal | Cumulative purchase amount. Automatically aggregated from POS transactions. |
LastVisitDate | DateTime? | Date of last visit. Automatically updated from POS transactions. |
Tags, memo, and audit
Tags (comma-separated), Notes (free text), Status (default "Active"; also withdrawn, blocked, etc.), CreatedAt, UpdatedAt.
Relationship with the POS
CrmCustomerDto is a POS-independent canonical model. Customers imported from a POS are linked to an RR customer ID and a POS-side identifier (the triple of vendor + identityType + vendorIdentifier) via a separate entity, PosCustomerLinkEntity.
For the bidirectional sync of member data with the POS, the conflict-resolution rules (whether the vendor side or the RR side is newer; per-field last-write-wins), and the priority order of matching keys, see Bidirectional member sync with Smaregi and Square.
Mapping from a POS vendor
Which fields of each POS's customer map to which fields of CrmCustomerDto is documented in the individual store-help articles.
- Mapping Smaregi member data to ReceiptRoller customer data
- Mapping Square customer data to ReceiptRoller customer data
Notes
- The combination of
OrganizationIdandCustomerIdis the unique key. Even with the same email address, a different business account is treated as a different customer. - Matching (duplicate detection) is checked in the order
MembershipCode→Email→Phone. For details, see Bidirectional member sync. VisitCount/TotalSpent/LastVisitDateare aggregated values. Even if you overwrite them directly, they will be overwritten again on the next transaction load.- Physical deletion of a customer is not recommended. Update the
Statusto withdrawn instead. If you physically delete on the POS side, matching on the RR side stops working.
Related guides
- PosTransactionDto reference — the canonical model for POS transactions
- Bidirectional member sync with Smaregi and Square
- Purchase and receipt data integration
- Back to the Developer Help top