# Email\_unsubscribed value inconsistent with customer preferences showing in Dashboard

**URL:** <https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185>\
**Category:** Questions\
**Tags:** customers-api\
**Created:** [August 10, 2021, 4:17pm UTC](https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185 "2021-08-10T16:17:06Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![cbstl](https://avatars.discourse-cdn.com/v4/letter/c/ee7513/32.png) [@cbstl](https://developer.squareup.com/forums/u/cbstl)\
**Post date:** [August 10, 2021, 4:17pm UTC](https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185/1 "2021-08-10T16:17:06Z")

</div>

Hello. I’m working on a Python script that uses the Square Customers API to get the Square customer list and import the contacts into another email marketing service. I’m using the preferences:email\_unsubscribed attribute from the Square API to determine the customer’s status for receiving marketing emails, but I’ve run into something odd. There are cases where some customers show email\_unsubscribed=True via the API, but when I look at their customer profile in the Square Dashboard, it shows them as Subscribed. This inconsistency seems wrong to me. Am I missing something about the email\_unsubscribed attribute in the API? Any insight would be appreciated. Thanks!

---

<div class="post-metadata">

**Author:** ![immanuel](https://avatars.discourse-cdn.com/v4/letter/i/cab0a1/32.png) [@immanuel](https://developer.squareup.com/forums/u/immanuel)\
**Post date:** [August 10, 2021, 4:36pm UTC](https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185/2 "2021-08-10T16:36:24Z")

</div>

Hello, will you be able to direct-message me the customer id and merchant id with the discrepancy? Our team can take a look.

- Immanuel

---

<div class="post-metadata">

**Author:** ![cbstl](https://avatars.discourse-cdn.com/v4/letter/c/ee7513/32.png) [@cbstl](https://developer.squareup.com/forums/u/cbstl)\
**Post date:** [August 10, 2021, 5:16pm UTC](https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185/3 "2021-08-10T17:16:40Z")

</div>

Hi Immanuel - I tried to send a DM with the info you requested, but got an error that said, “Sorry, you can’t send a personal message to that user.” Maybe because I’m new to the forums?

---

<div class="post-metadata">

**Author:** ![cbstl](https://avatars.discourse-cdn.com/v4/letter/c/ee7513/32.png) [@cbstl](https://developer.squareup.com/forums/u/cbstl)\
**Post date:** [August 10, 2021, 5:31pm UTC](https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185/4 "2021-08-10T17:31:49Z")

</div>

Here’s another data point that may be pertinent. I exported the customer list to CSV from the Dashboard and just spot-checking a couple of the contacts that have this discrepancy, the exported data has “unknown” in the Email Subscription Status column for them. Is it possible that when the underlying subscription status for a contact is “unknown”, the web Dashboard defaults to show them as Subscribed while the API defaults them to Unsubscribed?

---

<div class="post-metadata">

**Author:** ![szisman](https://avatars.discourse-cdn.com/v4/letter/s/ea5d25/32.png) [@szisman](https://developer.squareup.com/forums/u/szisman)\
**Post date:** [August 10, 2021, 7:06pm UTC](https://developer.squareup.com/forums/t/email-unsubscribed-value-inconsistent-with-customer-preferences-showing-in-dashboard/3185/5 "2021-08-10T19:06:46Z")

</div>

Immanuel is on vacation this week, but I can jump in here. I will DM you to collect the example customer\_ids so we can investigate. The theory you have here in your last post is plausible but would not be expected behavior so we should investigate this. Thanks for flagging!
