How Contacts With the "Gives Account Access" Flag Behave

Some contacts do more than receive marketing — they let a customer sign in to their account, earn points, and redeem rewards. Maestra treats those contacts differently from regular ones to keep account ownership unambiguous.

​

What the flag is for

A contact marked “gives account access” is the credential a customer uses to log in to your loyalty account or personal cabinet, accumulate points, and spend them. Three contact types can carry this flag:

• Email
• Mobile phone
• Discount card

​

Three rules Maestra enforces

Once a contact is marked as giving account access, Maestra applies three rules to protect account integrity:

1. A contact that gives account access is never overwritten during deduplication. When two customer profiles are merged, the account-access contact always wins — it cannot be lost or replaced by a contact from the other profile.
2. Re-registering with the same account-access contact is blocked. If a customer already exists with this contact, a new registration attempt using that same email, phone, or discount card will fail.
3. Two customers cannot be merged if their account-access contacts are of different types. A customer whose account access is a phone number cannot be merged with one whose account access is an email — the conflict prevents the merge.

​

How API lookups behave

When you query Maestra through an integration point that has account access enabled, the search runs only against customers whose contact is flagged as giving account access. If a customer exists in the database with that email or phone but does not have the account-access flag, the API returns a NotFound error — even though the contact value is in the database. The lookup is scoped to flagged contacts only, so an unflagged match is invisible to that integration point.

​

Worked examples

The examples below show how the three rules play out in real flows.

​

Example 1 — Customer without account access

A customer with phone number +1 555 123 1212 exists in your database, but the phone does not have the account-access flag. The customer visits a store and the cashier queries the loyalty API to check enrollment. Because the integration point has account access enabled, Maestra only searches flagged contacts — and this one isn’t flagged. The API returns NotFound, even though the phone number is on file. The cashier then registers the customer in the loyalty program. Maestra automatically merges the two records on the matching phone number, and the customer now has one profile with an account-access phone.

​

Example 2 — Re-registering a protected contact

A customer with phone number +1 555 123 1111 already exists, and the phone does give account access. Someone tries to register this customer in the loyalty program again with the same phone number. Maestra blocks the operation and returns an error indicating the customer already exists. Re-registration with a contact that gives account access is not allowed — rule 2 in action.

​

Example 3 — Newsletter subscription on a protected email

A customer with the email client@maestra.io exists in your database, and the email does give account access. The same email is later used to subscribe to a newsletter through a landing page. Because newsletter subscription does not require account-access status, the records merge normally on the matching email. The existing account-access email stays intact, and the subscription is attached to the same customer profile.

​

Why this matters

These rules protect the link between a customer and their loyalty account. Without them, deduplication could silently strip the credential a customer logs in with, or two distinct accounts could collapse into one and lose points history. The trade-off is that re-registration and certain cross-channel merges fail loudly instead of doing the wrong thing quietly — design your integrations to handle those errors as expected outcomes, not bugs.