[ANNOUNCE] Deprecating rarely called shipping-related methods

[Eric Stephens]

Hi everyone, 

We are currently working to improve the infrastructure behind our shipping tools. As a part of these upgrades, we need to deprecate a few rarely called shipping-related methods. We are also working on new shipping profile API methods that will replace most of these methods, and we'll keep you updated as we get closer to releasing the new methods.

Here are the methods we plan to deprecate:

getShippingTemplateEntry 

http://www.etsy.com/developers/documentation/reference/shippingtemplateentry#method_getshippingtemplateentry

updateShippingTemplateEntry 

http://www.etsy.com/developers/documentation/reference/shippingtemplateentry#method_updateshippingtemplateentry

deleteShippingTemplateEntry

http://www.etsy.com/developers/documentation/reference/shippingtemplateentry#method_deleteshippingtemplateentry

getShippingInfo

http://www.etsy.com/developers/documentation/reference/shippinginfo#method_getshippinginfo

createShippingInfo

http://www.etsy.com/developers/documentation/reference/shippinginfo#method_createshippinginfo

deleteShippingInfo

http://www.etsy.com/developers/documentation/reference/shippinginfo#method_deleteshippinginfo

These methods have almost no usage over the last two months and deprecating these methods will allow us to launch new shipping API methods faster.

We plan to deprecate these methods the week of Mon. 3 September 2012. Please let us know if you need more time and we will do our best to figure out a work around that gives you the time you need. 

Thanks, 

Eric

[david olick]

I think I was planning on using some of these.

Currently you do not associate listings with shipping templates, but rather have raw shipping information attached to listings.  Also, we can only update the shipping information of a listing using a shipping template (kind of backwards, considering some users do not use shipping templates at all)  I was planning on unify the listing update process on my site by gathering the shipping info of a listing to pre-populate shipping fields so I can then create and delete a temporary shipping template for the updating process.  Are you getting rid of access to listing's shipping information?

Eric

--
 
 

--
David Olick
Oriku Inc.

[Graeme Grant]

Hi Eric,
 
Our users have asked us and we are about to release an update for our app that uses the updateShippingTemplateEntry & deleteShippingTemplateEntry.
 
I kindly request that you do not remove these methods.
 
Kind Regards,
 
G.
 

---

Date: Tue, 21 Aug 2012 14:02:38 -0700
From: este...@etsy.com
To: etsy-...@googlegroups.com
Subject: [ANNOUNCE] Deprecating rarely called shipping-related methods

--
 
 

[david olick]

I am actually calling this quite reguarly: users/__SELF__/shipping/templates?includes=Entries

Would that API call be affected by the removal of the entries?

--
 
 

[Graeme Grant]

Shipping Templates is the second-most utilised feature of our users. Removing the ability to update the templates & shipping info will hurt the current development of our app - this is a feature that we planned on releasing this week.
 
It seems extremely odd that Etsy is considering removing valid API methods based on usage. 3rd-party API developers need time to find ways to make apps that use all the endpoints available in a way that the Etsy community can use. 
 
I'm sure that only 25% of the API method are highly utilised - does that mean that 75% should be removed also?
 
G.
 

---

From: david...@gmail.com
Date: Tue, 21 Aug 2012 16:32:44 -0500
Subject: Re: [ANNOUNCE] Deprecating rarely called shipping-related methods
To: etsy-...@googlegroups.com

--
 
 

[Graeme Grant]

Hobbling the API by depreciating underused endpoints will decrease the application diversity and creativity and forces up the number of "me too" apps competiting for the same users. It also makes many app developers concerned that their features are going to be taken away and breaking their apps.
 
The latter is what I have experienced in the past with other endpoints not fixed for months on end and/or removed. And this is yet another endpoint where the rug is being pull from under me.
 
Not happy.
 

---

From: grag...@hotmail.com
To: etsy-...@googlegroups.com
Subject: RE: [ANNOUNCE] Deprecating rarely called shipping-related methods
Date: Wed, 22 Aug 2012 07:43:31 +1000

--
 
 

[david olick]

Im a bit confused as to why these API calls were decided to be deprecated so quickly without any community feedback.

Making the feature I mentioned was something I had planned on doing a month or two ago and (luckily) decided to work on other things first.  I would have been quite upset if I had put in the effort to make it just to have it get deprecated a few weeks later.

This honestly makes me nervous about making new Etsy features on my website.  How am I supposed to know which API methods are commonly used and which arent?  Should I be polling the community before I start a project?  How much use is considered a lot and how much isnt?  These things make it oddly risky to use the API...

I hope to hear some feedback on my questions and concerns.

--
 
 

[Graeme Grant]

Shipping Profiles/Templates/Info are a key component of a Listing - just as key as images, tags, attributes. The shipping information is part of the overall cost/price of a product. Removing the ability to work with this pivotal part of a listing is like remove one or two wheels from a car - the API for managing listings will become incomplete.
 
We have already committed to our users and spent extensive time in researching and developing tools around this.
 
Today it was pointed out to me off-group that surprisingly only two developers were using these endpoints - so as far as Etsy was concerned that was ok. My mistake was to mock the endpoints during development of our tools - otherwise it would have been 3 developers. Would it have made a difference? Probably not. I don't understand their decion making process...
 
If Etsy need to reduce the number of endpoints, I can think of quite a few others that would be better suited to this type of mistreatment.
 
I 100% agree with you David, the 3rd party dev community were never part of the consideration process. I have had off-group commitments that this would not happen - now I feel like the fool for listening.
 
As there is no information sharing from Etsy on what is coming, we are left floundering in the dark making choices that cost us time,  money and users. Maybe there are new endpoints coming with the changes Etsy is making with shipping and maybe not ... maybe they're here next week or maybe another 2 years away like some endpoints that we have been asking for and been ignored to date... who knows...
 
I'm at a point where I have lost total confidence - so I'm going to freeze any new development as we are continuously kept in the dark, fed sudden changes/losses, and so the longevity of the endpoints is highly unreliable.
 
Justin & Chris, again, that changelog is **STILL** being ignored - 12 months on August 30!
 
 
G.
 
PS: Chad, I'm not sure if you are listening...
 

---

Date: Tue, 21 Aug 2012 22:27:04 -0500

Subject: RE: [ANNOUNCE] Deprecating rarely called shipping-related methods

From: redka...@gmail.com
To: etsy-...@googlegroups.com

--
 
 

[A.Yildiz]

I always expected / hoped that the API around the shipping infos would change, because the data model was not logical to me. Back then, it was repeatedly said that no changes were expected. That it had to be this way. So, I forced myself to work with it, or rather around it.

Some of those methods never worked for me anyway, but still I find it counter-productive to simply eliminate methods based on the number of calls. My app is relatively new and there might be apps that are in the pre-release state who spent a lot of time to work with these methods. If only you would announce the new replacement methods first, so that  developers could adjust.

I'm very concerned now.

[Jake Chapa]

Maybe if we can see a bar graph of the API methods, and the % of calls that they get, we can voice our concerns on the less-used endpoints before they get offed?

--    

[Jake Chapa]

Maybe if we can see a bar graph of the API methods, and the % of calls that they get, we can voice our concerns on the less-used endpoints before they get offed?

On Aug 21, 2012, at 11:12 PM, Graeme Grant wrote:

--    

[Graeme Grant]

When the Etsy Api was hosted by Mashery we had exactly that.

Etsy themselves have this type of information - from what I was told, this is how they made their decision.

Yet another way Etsy keeps us in the dark.

Sent from my Windows Phone

---

From: Jake Chapa
Sent: 23/08/2012 4:38 AM
To: etsy-...@googlegroups.com

--
 
 

[Graeme Grant]

Totally agree...

Sent from my Windows Phone

---

From: A.Yildiz
Sent: 22/08/2012 7:31 PM

To: etsy-...@googlegroups.com
Subject: Re: [ANNOUNCE] Deprecating rarely called shipping-related methods

I always expected / hoped that the API around the shipping infos would change, because the data model was not logical to me. Back then, it was repeatedly said that no changes were expected. That it had to be this way. So, I forced myself to work with it, or rather around it.

Some of those methods never worked for me anyway, but still I find it counter-productive to simply eliminate methods based on the number of calls. My app is relatively new and there might be apps that are in the pre-release state who spent a lot of time to work with these methods. If only you would announce the new replacement methods first, so that  developers could adjust.

I'm very concerned now.



Am Dienstag, 21. August 2012 23:02:38 UTC+2 schrieb Eric Stephens:

[Chris Dary]

Graeme,

We try to be as transparent as we can be. There are some situations, like this one, where for one internal reason or another, it's difficult to be as transparent as we would like.

As developers ourselves, we understand that changes we make can impact you in ways we don't expect. We're here to hear those and try to make them as painless as possible (to put actions behind these words: you'll notice that recently we've tried to accomodate timelines more explicitly in announcements by offering more time for people impacted.)

We welcome positive suggestions about ways to improve. Feel free to contact me off list if you'd like to discuss this further.

-Chris

--
 
 

[Eric Stephens]

Hi everyone, 

Thanks for the feedback. I'd like to clarify a few things. 

We plan to deprecate these methods because we are going to replace them with better methods, not because they are low volume. We originally planned to deprecate these methods shortly before releasing new methods because they are so low volume and we didn't expect it to disrupt anyone, but we posted here to find out if that was actually the case.

Based on your feedback we're looking into continuing to support these methods until sometime after the new methods are available, and we'll keep you updated here. 

Thanks, 

Eric    

[Graeme Grant]

Timeframe?
 

---

Date: Wed, 22 Aug 2012 13:38:49 -0700
From: este...@etsy.com
To: etsy-...@googlegroups.com

--
 
 

[david olick]

Thanks Eric (and Chris?) for extending the support for these methods until the new ones arrive. I know you might be under a lot of pressure to have things ready for the holidays.  Unfortunately we also have been trying to prepare with new features and improved websites.  Changing which methods you support so close to the season can put us in quite a panic... especially without knowing when methods to replace the removed ones will be available.

Not knowing what you are actively developing, what you are prioritizing, or any time estimates for things to be completed easily makes us worried when we hear things like this.  We have asked previously for a roadmap for expecting and upcoming changes in the past and if the removal of those API methids were something your team has been planning for a while, an active discussion could have occured without too many of us getting surprised by the announcement.  Letting us know long term goals would likely benefit everyone, even if some of the goals get derailed or delayed... it would easily let me make design changes with less future maintenance.

For example, I still dread an announcement that users will have multiple shops per account and that I have 2 weeks to fix it :) ... My code base doesnt currently support it and would require quite a bit of a re-write.  However if I knew you were planning that for next year I could start making changes now for a much better transition.

Again, thanks for extending the support for the methods.  But as Graeme asked... do you know of the timeframe which the new methods will be phased in and the old ones phased out?

--
 
 

[Graeme Grant]

I wish that I could feel as confident as David that these endpoints are remaining active. My take away was a little different as Eric said that "we're looking into continuing to support ". I would like to hear a solid commitment.
 
Chris mentioned that "We try to be as transparent as we can be". No disrespect to Chris as he is new but there is more transparency with sellers eg: beta testing of new features and dedicated forums during the development of new features - 3rd party developers get lumped with last minute changes - sometimes without warning or even announcements.
 
Chris highlighted "you'll notice that recently we've tried to accommodate timelines". The same situation as this one - a decision was made, short notice was given, then complaints and grovelling from the developers most affected by the short-sightedness of the decision forced Etsy to do a backflip. Sorry, but I don't see the difference Chris.  I'm still waiting for a solid commitment on a direction for these endpoints. Will it be the same for every other going forward?
 
Talking off-list does not benefit the 3rd party developer community... I'm still waiting to see words become actions.
 
The 3rd party developer community *is* a stakeholder in the API as we are  an extension of Etsy delivering services to the Etsy community yet we are kept more in the dark than it's sellers - this is not transparency. Transparency is where the 3rd party community is brought into the loop, constantly being kept up to date with the roadmap, the sandbox is primed with data and new features ahead of "go live" date so we can prepare, open discussion with the community and planning together. 
 
When the Sandbox was first released, it mirrored the main site and was a useful tool. After the sandbox was changed into its current state, it's supported poorly, buggy, unwieldy and pretty much useless - a total nightmare for new developers and a total embarrassment for Etsy.
 
"We welcome positive suggestions about ways to improve." Here's some:
* Be timely & respond
* Be open & transparent
* An up to date roadmap
* Involve the dev community like Etsy does with its sellers
* Consultative approach
* Sandbox needs to be fixed
* Sandbox for testing pending changes
* Sandbox needs a Web presence as promised 18+ months ago
* Keep documentation up to date with useful information
* A level playing field - all APIs open and not just some for the Etsy iPhone
 
I'm sure that there is more to add to this list.
 
If other developers are lurking, it would be good to hear your thoughts too.
 
G.
 

---

Date: Wed, 22 Aug 2012 18:25:13 -0500

--
 
 

[Chris Z.]

All I can say is that this is frustrating.

I'm sure I'm not the only one here where this is a "second" job and cannot muster all the time required to pull off changes in less than 2 weeks.  I didn't check the forums for a while and then I find this. 

There are many more questions here than I see answers for (what is replacing these calls, how long do we have?, etc.)

I agree with most of the points by the other developers here. I like Graeme's list - especially the comments about the sandbox.  It was useful - and now it not.

-Chris

[Nicole]

I'd just like to add my +1 on these comments - this conversation is almost identical to the one that occurred about a month ago regarding BillCharges - the only difference is that this affects a slightly different subset of API developers.

https://groups.google.com/forum/#!topic/etsy-api-v2/MUx0MJhRvTU

I would have liked to think that my comments regarding short lead times on breaking changes and adequate, transparent communication were considered, but from this latest example it unfortunately appears not.

I am seriously questioning the future for my app using the Etsy API - the stress of dealing with breaking changes with no notice coupled with the uptime issues of late has really made me wary of investing any further time developing my app forward which is really disappointing :(

[Julian L.]

I just wanted to note this is essentially what we experienced every step with Etsy from 2008-2011. Poor communication, questionable commitment, heart and stomach turning sudden changes, puzzling outages and a perceived a feeling of general lack of respect for developers and the API from Etsy produced doubt whether it's possible to build credible sites based upon on the Etsy API without constant maintenance, or at all. We . Thus, we're not very active in development at the moment.

I've hoped this is turning around for a good while now, so Etsy, please do let us know you're on the right track.

Julian

--
 
 

[Chris Dary]

Hi everyone,

1. There's a lot to speak to here. Give me until this afternoon to consider it all and speak to it properly.

2. This thread has fully derailed. I'll create a new thread to address these concerns this afternoon, but if we can, let's keep this one focused on the shipping methods, which Eric should be speaking to soon. As a reminder for those not following along, Eric noted that these changes are effectively paused: we're looking into continuing to support these methods until after the new ones have been provided.

I'll be following up on as many of your other concerns as I can later today.

-Chris

--
 
 

[Eric Stephens]

Hi everyone, 

We will continue to support these methods until after the new methods are available. We are still finalizing the new methods and will keep you updated on when we expect to release them. When the new methods are live, we will make sure you have enough time to switch over before we remove the old methods. 

Thanks, 

Eric    

[Graeme Grant]

Hi Eric,
 
Thanks for the confirmation on maintaining the endpoints. Is it possible to get an indication as to a timeframe for the new methods?
 
G.
 

---

Date: Thu, 23 Aug 2012 14:25:38 -0700
From: este...@etsy.com
To: etsy-...@googlegroups.com

Subject: Re: [ANNOUNCE] Deprecating rarely called shipping-related methods

--
 
 

[Eric Stephens]

Hi Graeme, 

We're still working on the new methods, so this is subject to change, but we're hoping to release them in the next 4-8 weeks. We'll post updates here. 

Best, 

Eric