{"id":3189,"date":"2026-10-04T00:06:41","date_gmt":"2026-10-04T00:06:41","guid":{"rendered":"https:\/\/dmarketertayeeb.com\/blog\/shopify-sms-consent-api-migration\/"},"modified":"2026-10-04T00:24:00","modified_gmt":"2026-10-04T00:24:00","slug":"shopify-sms-consent-api-migration","status":"publish","type":"post","link":"https:\/\/dmarketertayeeb.com\/blog\/shopify-sms-consent-api-migration\/","title":{"rendered":"Shopify SMS Consent API Migration: Update Phone Number Reads"},"content":{"rendered":"\n

Short answer:<\/strong> Shopify’s October 1, 2026 changelog adds CustomerPhoneNumber.smsMarketingConsent<\/code> in API version 2026-10<\/code>. Move Admin GraphQL reads to customer.defaultPhoneNumber.smsMarketingConsent<\/code> and Customer Account API reads to customer.phoneNumber.smsMarketingConsent.state<\/code>. Keep writes on the Admin GraphQL customerSmsMarketingConsentUpdate<\/code> mutation: its input still uses marketingState<\/code>, a different enum from the new read field’s state<\/code>.<\/p>\n\n\n\n

The announcement says the old flat SMS consent fields remain available for backward compatibility but are deprecated. It gives no shutdown date, so October 1 is the new field’s availability date, not a published removal deadline. Shopify’s changelog entry<\/a> names both the Admin GraphQL API and the Customer Account API.<\/p>\n\n\n\n

Where the new field lives<\/h2>\n\n\n\n

The objects differ slightly by API surface. Admin GraphQL exposes the full structured consent record. The Customer Account API exposes only its current state on the structured consent object.<\/p>\n\n\n\n

Admin GraphQL API<\/h3>\n\n\n\n

Start from Customer.defaultPhoneNumber<\/code>, then select smsMarketingConsent<\/code>. The current object includes state<\/code>, optInLevel<\/code>, collectedFrom<\/code>, sourceLocation<\/code> and updatedAt<\/code>. The old sibling fields marketingState<\/code>, marketingOptInLevel<\/code>, marketingCollectedFrom<\/code>, marketingUpdatedAt<\/code> and sourceLocation<\/code> are deprecated on CustomerPhoneNumber<\/code>. Shopify lists those flat paths on the Admin CustomerPhoneNumber reference<\/a> and the nested fields on the CustomerSmsMarketingConsent reference<\/a>. The phone-number reference requires read_customers<\/code>.<\/p>\n\n\n\n

query CustomerSmsConsent($id: ID!) {\n  customer(id: $id) {\n    id\n    defaultPhoneNumber {\n      phoneNumber\n      smsMarketingConsent {\n        state\n        optInLevel\n        collectedFrom\n        updatedAt\n      }\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
In this Admin query, $id<\/code> is a variable for an existing Shopify Customer GID; the illustrative example contains no real customer identifier. Shopify’s Admin Customer reference<\/a> marks defaultPhoneNumber<\/code> nullable, so handle the case where a customer has no default phone number. This minimal selection leaves out sourceLocation<\/code> because that field returns a Location<\/code> object. To request sourceLocation { id name }<\/code>, the app also needs one of read_locations<\/code>, read_inventory<\/code> or read_markets_home<\/code>; read_customers<\/code> alone does not cover that expansion. See Shopify’s Location reference<\/a>.<\/p>\n\n\n\n
Customer Account API<\/h3>\n\n\n\n
The Customer Account API starts from Customer.phoneNumber<\/code>. Its structured smsMarketingConsent<\/code> object exposes only state<\/code>; asking for Admin-only fields such as optInLevel<\/code> or updatedAt<\/code> does not match this surface’s schema. The Customer Account CustomerPhoneNumber reference<\/a> documents that object and requires customer_read_customers<\/code>; apps using the API must also meet Shopify’s protected customer data requirements<\/a>.<\/p>\n\n\n\n
query AccountSmsConsent {\n  customer {\n    phoneNumber {\n      phoneNumber\n      smsMarketingConsent {\n        state\n      }\n    }\n  }\n}<\/code><\/pre>\n\n\n\n
The argument-free Customer Account customer<\/code> query returns the currently authenticated buyer’s record. The Customer reference<\/a> marks Customer.phoneNumber<\/code> nullable, so a buyer can have no phone record; separately, the nested phone string can be withheld when protected-data access is not approved. Shopify shows the redaction behavior in its protected-data requirements<\/a>.<\/p>\n\n\n
Customer Account requests use an access token associated with the buyer, while Admin GraphQL uses an app token acting for the merchant and the Customer GID above. Shopify explains this distinction in the Customer Account authentication reference<\/a> and its API authentication overview<\/a>. These source-checked examples have not been executed; the article includes no real customer ID or credentials.<\/p>\n\n\n\n
Replace read paths, not just field names<\/h2>\n\n\n\n
For Admin GraphQL, map the deprecated fields on CustomerPhoneNumber<\/code><\/a> to the nested fields on CustomerSmsMarketingConsent<\/code><\/a> as follows:<\/p>\n\n\n\n