However, none of the listed Authenticated or Unauthenticated sections list the Cart resource, so I have no idea which access scope I need to request in order to start implementing this.
Additionally, I have no idea if this mutation requires authenticated or an unauthenticated Storefront access token.
I assume the latter, since you can apply cart attribute changes through the AJAX storefront API. But at least having this documented would be nice.
I’m not the only developer facing issues integrating with this API:
Hey @Dylan - all Storefront API calls are technically unauthenticated like you mentioned there. We do differentiate between a public and private Storefront Token though (a bit more info here), but the access scopes for each would be the same.
That said, I did a bit of digging through the docs, and like you said, I can definitely see how it would be a little unclear as to how the cart-specific mutations/queries work on the Storefront API.
Technically, if you have a Storefront API token there is no additional access scope needed when it comes to carts specifically (which is why it’s not popping up in the docs unlike for a customer-related mutation on the SFAPI: customerAccessTokenCreate - Storefront API which requires additional unauthenticated scopes).
Basically, once you have a Storefront Access Token generated, you can create/manipulate carts without any additional scopes required.
I’ll set up a note as well for us to take a look at updating the docs to make this clearer for sure. Hope this helps - let me know if I can clarify anything on our end here.
Please see my other post about permissions issues with creating a storefront API token here:
Since this mutation should create an unauthenticated SF access token, shouldn’t the mutation just work?
I’m reading through another Storefront API guide (linked below), it’s mentioning enabling the Storefront API on the Shopify store itself first.
Do merchants need to enable the Storefront API in their Shopify store’s setting in order for installed Shopify apps to leverage the Storefront API on their behalf?
Hey @Dylan - good to see you again in the forums here too!
I get where you’re coming from now, thanks for clarifying that. I did a bit more digging, and it looks like unless you’ve already configured at least one unauthenticated Storefront Access scope to be requested (either upon app set up or in an update in your TOML if you’re using our template, or wherever you store your access scopes), the request to create a new token will fail.
I can’t see this mentioned in our docs anywhere, so I’ll add that to the note I set up on my end here to see if we can add that to the docs. One thing I also noticed, is that if you’re using a 1P app like the GraphiQL explorer in the shop’s admin, the storefront access token also can’t be created that way (even if the GraphiQL app has the right storefront scopes.). The app requesting token creation has to be an external client (you can request storefront tokens using a GUI API client like Postman though).
I did a bit more digging, and it looks like unless you’ve already configured at least one unauthenticated Storefront Access scope to be requested
Got it, so I assume you mean picking at least one unauthenticated_* access scope listed in this table:
I’ll implement the scope change on my dev store and see if I can create a StoreFront Access Token. Will report back here.
I have a DIY CLI tool that imports mutations/queries and executes them so I can just reuse the queries/mutations in-app without rewriting them.
Last note, the Checkout object documentation is missing for the latest version of the API 2025-04. Curious about this API in particular, but maybe it’s not available yet?
Exactly @Dylan - you’re on point, basically any one of those unaunthenticated… scopes should work.
Personally, I generally just enable all the unauthenticated storefront scopes when I set up a new app if I’m going to be using the SFAPI from the get go - I don’t know if it’s confirmed best practice, but that’s what I’ve seen a lot of partner devs do as well, so I think it’s safe to share that as a recommendation just from my perspective here.
The checkout object being referenced in the docs there is likely the deprecated checkout object (there’s a bit more on this here).
My understanding is that the storefront checkout API has been fully sunset, so I’m thinking the reference to it there is most likely due to legacy reasons, but I’ll speak with some folks on our end here to see if that should be removed or if there is a reason we can share for that still being present in the docs - thanks for flagging though, much appreciated!
- all Storefront API calls are technically unauthenticated like you mentioned there. We do differentiate between a public and private Storefront Token though (
