[stickfigure]

I built a print-on-demand system that integrates into Shopify stores. To vent a little...

* I can concur that their API is unreliable. About 1 in 5 of my CI runs fail with mysterious 500 errors. It's infuriating.

* The support channels are a wasteland. Do not expect help.

* The documentation is super thin. At first glance it looks decent - there's the objects, there's the fields those objects have. But it's missing all the details about how those fields are supposed to work. Example: A Fulfillment has a tracking_numbers array, but there doesn't seem to be any way to add multiple tracking numbers. The docs are silent, and questions about this in the support channels remain unanswered. For years.

* There are two completely different APIs (graphql and REST), which do not have equal capabilities. If Shopify is planning on deprecating one of them, they should give us guidance.

* The API is inconsistent. I count at least FIVE different representations of an Address structure, each slightly different for no apparent reason. Eg "country" vs "countryCode". This is the kind of thing that creeps into projects in dynamic languages when nobody's paying attention.

* There's a lot of overengineered stuff. The Metadata API is really unpleasant compared to Stripe's simpler approach.

* There's no way to set up common shipping scenarios like "$N for first item, $M for each additional".

I could go on. But I will say this: It's better than Etsy's API. Though Etsy is finally working on it again, so maybe that will change.

[8note]

Naming differences are the product of having names and enough surface area to where you can't remember all of what's in the API at once imo.

You can get variations in 2 digit country code vs 3 digit vs some other representation easily regardless of what language you're using

[ylyn]

If you had a statically-typed language, you could have a single Address type and that's that.

[dreamer7]

That is definitely easier to work with but may not solve all problems. In the parent example, they mention Country and CountryCode. What if one team decided that they needed codes and the other needs the full name?

There has to be company-level standards to ensure consistency. And it is so hard to enforce standards unless a culture of revisiting and generalising things is created while growing from a small team.

[HighlandSpring]

It is not hard to standardise an Address type across a company (they are a shopping product after all)

Or better yet, define which types are required and which are optional so at least naming is consistent

[km3r]

As someone who has worked on addresses for a large corperate system, addresses can get very complicated. International localization, formatting, different usages (shipping, billing, mailing, taxes), multiple addresses per user, and security all start to add up, with many different part of the application having different requirements. Even as the team that owned addresses we debated whether new use cases should spin up their own implemention. Though it's pretty interesting seeing how different countries do addresses differently.for example, users in South Korea expect to be able to search for addresses and just enter an apartment number. Some countries went to near 9 lines of info.

[stickfigure]

Shopify does not have this problem. There is no excuse for these addresses to be different. Case in point - look at Order vs FulfillmentOrder. The destination is a simple copy! Even worse, FO is missing the country code and province code, including only the (useless for shipping) full text. It's daft.

A typed language helps because you would have to make an explicit decision to use a non-standard Address. And the 2 vs 3 digit country code conflict is an issue with "stringly typed" code; don't do that, make a CountryCode type instead and constrain it.

[flower-giraffe]

> About 1 in 5 of my CI runs fail with mysterious 500 errors. It's infuriating.

I see these daily, with errors that suggest the cloudflare layer is unable to connect to origin.

[arduinomancer]

The inconsistency thing is likely just different teams/people working on the API.

I’d bet very few people who work there know all the APIs that exist.

[ARandomerDude]

Regardless of the proximate cause, it's very frustrating when companies don't prioritize good documentation.

[disantlor]

There are definitely several ways to set up complex Shopify shipping situations. My livelihood is in good part based on it.

[stickfigure]

Oh sure... I make everything one pound, and create fixed rates for 1#, 2#, 3#, etc... but there's a (low) finite number of entries you can add, so if someone orders more than N units, they get free shipping for the rest. It's a terrible workaround. Etsy does not have this problem.

Or perhaps you are thinking about creating a carrier service, so Shopify will fetch shipping prices in realtime? That's for people on Shopify Plus plans, which costs $2k/mo+.

Actually, that's not quite true! There's a wholly undocumented option for non-plus merchants to get the carrier service feature enabled on their account for a monthly fee of something like $25. They have to reach out to support.

Everything with Shopify is like this. Great for consultants who have already internalized all this knowledge, sure.

[disantlor]

but why should it necessarily be that much different? better documentation sure, always. but in my experience Shopify solves ~70% of the cases extremely well and I, having learned some of the quirks, have very little problem filling the gaps. I will say, the app development, to the point of the article, IS a bit annoying hah. But I'm very surprised by all these API complaints. I think the API is very nice; maybe not quite Stripe-level but highly effective.

[yunohn]

So your job is being a gatekeeper for Shopify’s shipping setup capabilities?

[mrgreenfur]

This is a great list, ill add in that there is no partner UI for billing obejects. If you lose a secret token then no one can access it, even though shopify has it on record and you have to beg the client to press uninstall.

Support is friendly and prompt but knows nothing about the apis.

[theturtletalks]

Hey, I'm building an e-commerce operations platform that let's you connect any e-commerce platform to fulfillment and 3PL platforms. We're integrating with Printly and the like right now. Is there an API for your platform yet?

[stickfigure]

Yes, although you'll probably find that we are not an obvious fit for that model. Company info is in my profile.