Create and Update Customer

Use these endpoints to enroll a Customer into Loyal Guru, keep the profile current, or delete/anonymize when required by privacy processes.

Always get or search first when the channel might already know the person — creating blindly is the main source of duplicates.

Endpoints

Action	Endpoint
Create / enroll	POST /customers
Update profile	PATCH /customers/{value}
Delete / anonymize	DELETE /customers/{value}

OpenAPI: Customer endpoints · API Reference

Create — POST /customers

Purpose: register a new Customer (loyalty enrollment or first sighting in a channel).

Unified database pattern

When POS, e-commerce, app, and CRM already share one Customer ID, create or update once and reuse that ID on every loyalty action — no merge required.

If e-commerce and offline channels use different IDs, see Customer Data — separate online/offline and Merge.

Implementation notes:

• Send a stable external ID when the retailer has one (unified database pattern).
• Include consent and contact fields required by the Company configuration.
• Support referred_by when referral programs are in scope.
• On unique-field conflicts, do not create a second Customer — search, verify, then merge or update.

Update — PATCH /customers/{value}

Purpose: change profile attributes without changing Customer identity.

Use for email/phone corrections, consent changes, address, preferences, and operational flags. Prefer PATCH over delete+create so points, vouchers, challenges, and history stay on the same Customer ID.

To reactivate a Customer set to inactive by Inactivity Lifecycle (or by a manual block), send status: "active". A new cart alone does not reactivate the Customer.

Delete / anonymize — DELETE /customers/{value}

Purpose: remove or anonymize a Customer per privacy / GDPR-style processes.

Confirm with the Loyal Guru team whether the Company uses soft anonymization or hard delete (hard=true where supported). Deletion can affect reporting and open vouchers — coordinate with ops before running bulk deletes.

The same soft anonymization path is used when Inactivity Lifecycle automatically moves dormant Customers to deleted. Downstream systems that subscribe to customer / delete should treat automated and manual anonymization the same way.

Custom fields → Attributes

Legacy integrations may still write or read custom1–custom11 (text) and custom1f–custom8f (numeric) on POST /customers, PATCH /customers/{value}, and GET /customers/{value}. These fields are deprecated — use the attributes object instead.

	Legacy custom fields	Current model
Field	custom1…custom11, custom1f…custom8f	attributes (freeform key-value object)
Shape	Fixed, numbered slots	Named keys, JSON Schema-validated
Configuration	None (implicit)	Owner App: Configuration → Company → Custom Attributes
Constraints	11 text + 8 numeric slots	Single-level only, max 50 attributes, 10 KB total; unknown properties are silently discarded

attributes is returned in GET /customers/{value} and accepted in POST /customers / PATCH /customers/{value}.

note

Not the same as Calculated Attributes. GET /customers/{id}/attributes is a separate, unchanged entity — auto-derived KPIs computed by Loyal Guru from ingested data (purchase frequency, spend, etc.), configured under Data Management. Migrating custom fields to attributes does not affect calculated attributes.

Related flows

Situation	Guide
Need to resolve existing Customer first	Get Customer
Two enrollments for the same person	Merge
Add a physical loyalty card	Associations and Cards

Troubleshooting

Symptom	What to check
Duplicate Customers after enrollment	Channel skipped GET/search; unique email/phone already existed
Profile update “lost” history	System created a new Customer instead of PATCHing the existing ID
Create returns conflict	Search the conflicting field and decide update vs merge
Consent not respected in campaigns	Confirm consent fields were sent on create/update and synced to audiences