This is a post from Robin Sloan’s lab blog & notebook. You can visit the blog’s homepage, or learn more about me.

Further adventures with the doc bot

July 14, 2025

I don’t mean to pile on, but I just feel like this should be doc­u­mented (ha) somewhere.

This morning’s ques­tion for the Shopify doc bot seemed to me right in the bullseye for this kind of tool:

what is the non-deprecated replace­ment for email­Mar­ket­ing­Con­sent on the cus­tomer object?

The reply:

Thus spake doc bot
Thus spake doc bot

In case that image is too small to read on, e.g., a mobile screen: the doc bot says I should now use the mar­ketingConsent field: “a uni­fied object that con­tains both email and SMS mar­keting con­sent infor­ma­tion.”

The problem (you have fore­seen it): there is no mar­ketingConsent field.

After poking around for a while — maybe ten minutes? — I answered this ques­tion for myself. The new structure tucks the con­sent info into the email address field, like so:

query {
  customerByIdentifier(identifier: {
    emailAddress: "foo@bar.com"
  }) {
    id
    defaultEmailAddress {
      marketingState
    }
  }
}

This requires switching to API ver­sion 2025-07, which is what tripped me up; I’d been on 2025-01.

I’ve tried my orig­inal doc bot query a few more times, incognito, and received dif­ferent replies; none were as mis­leading as the first, but/and none of them betrayed any aware­ness of the new structure, either. So, okay, an unlucky roll of the dice! I’m not sure how to think about “probabilistic docs”.

Keeping com­plex doc­u­men­ta­tion aligned with a fast-changing API isn’t easy, so it’s not like I expect zero errors or omis­sions in these resources — it’s just that I don’t think the doc bot is helping!

To the blog home page