We’ve updated our API ToU and Partner Program Agreement

Retired Boards Appdev Custom Storefronts
21

No worries Karl, better safe than sorry. Private apps, new or old, are not affected.

22

Awesome, thanks once more @Shayne !

23

Our competitors in the face of Bold, One Click Checkout and Carthook have all released statements, that their custom checkouts have been authorized to keep working. What are the rules/conditions that we need to comply with to get this authorization? Who can we talk to? Also, what will happen to our current customer base?

Thank you to @Shayne and the Shopify team for the clarifications. It’s a Friday, so extra props and thank you’s for your quick responses!

In regards to @leteyski 's comments, could @Shayne or someone from Shopify comment about it? For example, my software sells a combination of a software product/customization service using private APIs. As outlined in the Terms of Use, we don’t use Shopify’s OAuth/Public App Store integration, but technically speaking, we do have a URL (our website) where customers can come and go through the installation to see how things work and contact us for further customization needs within our software.

Again, thanks again to Shopify’s team in addressing this change. How you guys have responded really puts into focus the word “Partner” in Shopify Partners.

24

I’ll throw my hat in the ring here, and welcome clarification from whoever might want to pitch in. I’ve already contacted Shopify directly, but it would be nice to get a broader opinion on this.

We’re a few weeks into developing an integration between our standalone inventory management and point of sale system and Shopify. Our plan is to start by coupling as loosely as possible with Shopify by only syncing items first listed on our end with Shopify products. We’ll then track all quantity changes to keep inventory levels in sync for this subset of the merchant’s items, and listen for sales so we can handle some consignment workflows.

The customer data requirement is not a showstopper for us, but it doesn’t seem to make much sense because Shopify’s justification for the policy is to provide the merchant access to their customer data (which we do). However, our merchants have already chosen to trust us, and we’re referring them to Shopify as an ancillary partner. What makes Shopify more trustworthy than our software? Additionally, our point of sale is only meant to be used for brick-and-mortar sales, not for web sales, which makes the segment of customers we track in our software pretty distinct from the segment of customers who purchase items through Shopify. It seems to me that the merchant has entrusted us with brick-and-mortar customer data; Shopify with online customer data. Finally, it’s the merchants themselves who enter data into our system, at no time do we interact directly with the customer.

The bigger issue for us, of course, is the requirement to use Shopify’s own checkout. The criticism that a checkout experience might be bad for a customer doesn’t really hold water for us, since our checkout experience is merchant-facing; again, at no point do we interact directly with a customer. Like several other folks in this thread, our POS is custom-made because it supports some specific use cases having to do with our market. Additionally, the same argument applies that Shopify’s value-add for us here has nothing to do with brick-and-mortar sales, we’re more interested in using Shopify to enable our merchants to make online sales. It sounds like we can apply here for an exception, and there’s no reason for Shopify to turn us down, but I also am curious about the details of how to go about that, on what criteria the checkout is judged, etc.

I was also curious to have a few terms defined, specifically with reference to our use case, where we’re less of an app, and just as much a “platform” as Shopify is.

  • The distinction between public and private is still unclear to me. As defined in the ToU, public apps are “made available to Merchants either via a URL or through the Shopify App Store.” Ours is authenticated using OAuth, and is meant to be used by multiple stores generically, but it isn’t accessible at a public URL or in the App Store, but rather via an authenticated settings page, under a pre-existing ToS agreement with us. Is that public or private?
  • In 2.3.18, the ToU says “not use an alternative to Shopify Checkout for web checkout or payment processing”. Is “web” associated with “checkout” only, or does it also qualify “payment processing”. If the restriction is only for online checkout/payment processing, then it sounds like brick-and-mortar checkouts aren’t restricted.

Sorry if this was a bit long-winded! It’s a complex matter, and appears to have some major potential downsides for us, to the point that we’d have to abandon Shopify for an inferior solution. Shopify is the best out there though, so we’d love to make this work.

25

All data relating to a merchant’s customers that a partner collects on behalf of the merchant (excluding any sensitive personal information) must be sent back to Shopify.

I’d like some clarification on this as well. We are a platform that enables merchants to chat with their customers online, through email and social channels. This means that any email the merchant receives at their email channel or through those channels, appear on our platform. In those conversations, we collect the other party’s name and email address, and the contacts which exist on our platform for a merchant might or might not be relevant to Shopify (could be that the merchant is in an email conversation with another app provider), so it doesn’t seem to make a lot of sense to sync the data back to Shopify. In fact there’s no real way of determining whether a contact is relevant to Shopify as a Customer resource or not.

The other issue is that if multiple apps collect name + email + phone, and with each app syncing their own version of the data back to Shopify, wouldn’t that conflict (last write wins) and possibly mess up the customer information on the Shopify side? Wouldn’t this also result in a large number of Shopify Customer objects being created on the merchant’s store, regardless if the customer was actually a customer or purchased anything?

26

Can we please get some clarification on this?

27

Thanks for updating the language but also have questions similar to @heng .

We are very different from other folks here - we are a Private App that uses the APIs to extract data and build marketing models for our clients including direct mail models. We at times will get updated suppression lists from their direct mail or email platforms. Do we need to push back this updated marketing information into the customer model?

Thanks,

Dan

28

I’ve just read the updated ToU section 2.3.17, and the justification provided in the email sent out today seems fair. Thanks for qualifying that, Shopify.

I’d still be interested in some clarification of the terms I listed above, i.e., public vs private apps, and the nature of transactions subject to the checkout API.

29

Hi Shopify Team,

Thanks for the email and update on API License and Terms today.

One question for us. If we utilize API to pull in our customer and order data and then also separately use Mailchimp APIs to pull in our email data, do we need to update Shopify accepts_marketing and accepts_marketing_updated_at because Mailchimp will no longer be directly connected. Currently we don’t update because we assume the Mailchimp integration takes care of it.

Thanks,

Dan

30

Is anyone replying to this thread anymore. Please can you clarify this point:

In the API Terms, section 2.3.18 says this:

“not use an alternative to Shopify Checkout for web checkout or payment processing, or register any transactions through the Shopify API, without Shopify’s express written authorization.”

Does this mean that we’re no longer able to use the Orders API Create Transaction endpoint at all for any reason without Shopify’s permission?

31

These restrictions don’t apply for private apps. I hope Shopify continue to reinforce this.

32

@Shayne

Too late… our app just got blocked by Shopify.

The fact Shopify effective blocked the installation of our app before warning us just make things looks even more wrong. According Shopify TOS, as also discussed on this thread, our app did not break any rules, I made a lot of research before putting 6 months of work with other 6 developers on the team.

The API Terms Section 2.3.18 says not to use an alternative to Shopify Checkout for web checkout or payment processing, or register any transactions through the Shopify API, without Shopify’s express written authorization.

But it also says the following: This Section 2.3.18 only applies to Public Applications. Again, as also discussed in this thread.

We have a private app, that completely replaces Shopify checkout, therefore we did not break any rules whatsoever.

In the email Shopify sent me, it was written: “Additionally, due to the installation requirements (disabling Shopify checkout, adding javascript), this has been causing an increase in support debt for Shopify’s support team.”

Here is the thing - merchants do not have to disable Shopify checkout and add any Javascript whatsoever. There is not cause for increase in support for Shopify’s team. Our merchant simply have install our app. That’s all. Just like our competitors do. So I really don’t understand what is happening.

Like one of the guys here previously said: “Now, how come I, as a Partner, have been put in a disadvantageous position when it comes to delivering solutions for my clients, while others do the same.”

Here is a few similar apps running the same kind of solution that we do, without any blocks:

The decision Shopify took on us totally breaks the Partners trust we put in Shopify while building apps for merchants.