> ## Documentation Index > Fetch the complete documentation index at: https://help.lobyco.com/llms.txt > Use this file to discover all available pages before exploring further. # Customers and loyalty cards > What Lobyco holds about a customer, how your backend keeps it in sync, and the rules on deactivation, deletion, cards and linked customers. The customer record is the identity everything else hangs off. Purchases, coupons, bonus balances and receipts all refer to it. Your backend creates and updates customers from your master system, and admin users see the result in Lobyco Nexus. This page is what Lobyco holds about a customer and how your backend keeps it in sync. It also sets out the rules on cards and linked customers. The API calls a customer a *member*: `/v1/members/{memberId}`. > [!WARNING] > > **Deactivating a customer deactivates their loyalty cards too.** Deleting a customer is permanent: the data is removed and the customer is anonymised, with no undo. Design your support flows around both. ## What Lobyco holds about a customer Which of these Lobyco keeps depends on the services you run. | Data | What it holds | | - | - | | Customer | Identifier, email, address, loyalty programme or tier | | Bonus | Money bonus and points accounts, their history and the full ledger | | Store | The customer's preferred store | | Receipt | Generated from the purchase transaction log | | Consent | Acceptance of terms and conditions, data protection and marketing opt-ins | | Card payments | Payments made with cards registered in the app | | Loyalty card | One or more cards, physical or virtual, used to check in at the POS | All of it is available to the mobile app, to admin users in Nexus, and to the third-party services you expose it to. ![Six sources feed the customer view in Nexus: the member, bonus, store, receipt, consent and identity services. Card payment, payment and loyalty card services feed it as optional sources.](https://mintcdn.com/lobyco-4c9fb3ad/gBSKN_1oukwvI2rY/images/loyalty-and-membership-01-customer-data-sources.png?fit=max\&auto=format\&n=gBSKN_1oukwvI2rY\&q=85\&s=91176638eda1ae9264f94b19eb7b1db6) *What the customer view in Nexus is built from; the three dotted sources depend on the services you run* ## Customers Your backend loads customers with [POST /v1/members/import](/api-reference/loyalty-and-membership/members/post-v1-members-import). It is an upsert: a record whose `memberId` exists is updated, any other is created. Each record carries: * `memberId`, your identifier for the customer, stable over time. It is the matching key. * `isActive` and `createdAt`. * The profile: the names, `email`, `phone`, `birthdate`, `genderId`, `nationality` and the `address`. * `selectedStoreId`, the customer's preferred store. * `loyaltyProgram`, the programme or tier, such as `Silver` or `Gold`. * `metadata` and `customProperties`, your own attributes. The first three are required. Read one customer back with [GET /v1/members/\{memberId}](/api-reference/loyalty-and-membership/members/get-v1-members-memberid). Find one with [GET /v1/members/search](/api-reference/loyalty-and-membership/members/get-v1-members-search), by `Id`, `Email`, `Phone`, `PersonalId`, `SelectedStoreId` or `LoyaltyCardId`. [PATCH /v1/members/\{memberId}](/api-reference/loyalty-and-membership/members/patch-v1-members-memberid) changes single fields. ### Cooperatives A customer can belong to local cooperatives, which grant type-specific bonuses. Admin users see them in Nexus but cannot change them there. They are set through the API. ### Changes history Every change to a customer is recorded with a timestamp and the initials of who made it. That covers creation, edits by the customer or an admin user, activation and deactivation, and a change of preferred store. Admin users see the list on the customer's overview in Nexus. They can attach a note to a change, or a note about the customer, typically after a support call. ### Deactivating and deleting a customer [PUT /v1/members/\{memberId}/deactivate](/api-reference/loyalty-and-membership/members/put-v1-members-memberid-deactivate) suspends the customer. It takes a `reason`, a `timestamp` and who made the change in `changedBy`. A customer who is signed out can no longer sign in. One who is signed in sees a notice and is signed out when they dismiss it. Their loyalty cards are deactivated with them, and the reason goes into the changes history. [PUT /v1/members/\{memberId}/activate](/api-reference/loyalty-and-membership/members/put-v1-members-memberid-activate) reverses it. [DELETE /v1/members/\{memberId}](/api-reference/loyalty-and-membership/members/delete-v1-members-memberid) removes the customer and anonymises their data. It takes a `reason` and a `deletionMode`: * `Immediate`, the default: the customer is deleted now. * `Notification`: nothing is deleted. Lobyco emails your administrator, who processes the request by hand. ## Loyalty cards A customer holds one or more cards and checks in at the POS with an active one. That is what earns benefits and makes coupons redeemable; see [Registering at POS](/integration/pos-point-of-sale-integrations/registering-at-pos). | Aspect | Values | | - | - | | `type` | `Physical` or `Virtual` | | `state` | `Active` or `Inactive` | | `cardHolderType` | A label of your choice, such as `Member` or `Employee` | [POST /v1/loyalty-cards](/api-reference/loyalty-and-membership/members/post-v1-loyalty-cards) creates a card for a `memberId`. Give it a `cardId`, or leave it out and Lobyco assigns the next barcode from a queue you have loaded. Send an `operationId` on every call. It is the idempotency key, so a retry does not create a second card. Set the `replaceActive` query parameter to deactivate the customer's other active cards at the same time. Two limits apply, and both are configured for your environment: * The number of active cards per customer. A call that would exceed it is rejected, and so is an import row. * The barcode ranges and prefixes a `cardId` must fall within. [GET /v1/loyalty-cards](/api-reference/loyalty-and-membership/members/get-v1-loyalty-cards) lists a customer's cards, filtered by `state`. [PUT /v1/loyalty-cards/\{cardId}](/api-reference/loyalty-and-membership/members/put-v1-loyalty-cards-cardid) activates or deactivates one card. [POST /v1/loyalty-cards/\{memberId}/deactivate](/api-reference/loyalty-and-membership/members/post-v1-loyalty-cards-memberid-deactivate) deactivates all of a customer's active cards. Admin users add, activate and deactivate cards in Nexus, where a customer's physical and virtual cards are listed together. ### Decoding barcodes Lobyco turns a raw scanned barcode into structured data with templates. A template describes how one kind of barcode is built. It has a name and a type, such as an article or a voucher, and a minimum and maximum length. It says which code identifiers appear and where they sit, how the data tokens are extracted, and how the result is validated. Decoding runs in a fixed order: 1. Match the barcode to a template. When several match, one is chosen. 2. Validate it against that template's rules. 3. Extract the data. Extraction runs whether or not validation passed. Check the validation result instead of assuming a returned payload is valid. ## Linked customers A link joins two customer records: an additional cardholder on the same membership, or two memberships merged into one. [POST /v1/linked-members](/api-reference/loyalty-and-membership/members/post-v1-linked-members) creates one, with a `primaryMemberId`, a `relatedMemberId` and a `relationshipType` of `AdditionalCardHolder` or `MergedMembership`. Both customers must exist and be active. A duplicate link is rejected, and the feature is switched on per environment. Links are bidirectional: [GET /v1/linked-members/\{memberId}](/api-reference/loyalty-and-membership/members/get-v1-linked-members-memberid) returns them from either side. [DELETE /v1/linked-members](/api-reference/loyalty-and-membership/members/delete-v1-linked-members) removes one, and deleting a customer removes their links with them. ## Importing in bulk Customers, loyalty cards and linked customers import the same way. Each is a synchronous bulk upsert that creates and updates in one call, validates every record at once, and answers with a result per record. | Import | Operation | Rules | | - | - | - | | Customers | [POST /v1/members/import](/api-reference/loyalty-and-membership/members/post-v1-members-import) | `memberId` is the matching key | | Loyalty cards | [POST /v1/loyalty-cards/import](/api-reference/loyalty-and-membership/members/post-v1-loyalty-cards-import) | The customer must exist; the active-card limit and the barcode rules apply | | Linked customers | [POST /v1/linked-members/import](/api-reference/loyalty-and-membership/members/post-v1-linked-members-import) | Both customers must exist and be active | Because validation is per record, a batch can partly succeed. Validate before you send, to keep the failure rate down. Use stable identifiers, so a retry matches the same records. Read the response instead of assuming the batch went in, and retry only the records that failed. ## API reference Endpoint documentation: [Members](/api-reference/loyalty-and-membership/members). ## Related * [Consent](/integration/loyalty-and-membership/consent) — what a customer has agreed to, and how acceptance is recorded. * [Import audiences from your system](/integration/loyalty-and-membership/import-audiences-from-your-system) — lists of customers that activities and channels target. * [Registering at POS](/integration/pos-point-of-sale-integrations/registering-at-pos) — how a loyalty card identifies the customer at the checkout. * [Payments](/integration/pos-point-of-sale-integrations/payments) — card payments made in the app. * [Transaction data](/integration/pos-point-of-sale-integrations/transaction-data) — the purchases and receipts that hang off the customer. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.