Coupon / Discount Codes API

[tarwin]

Hi,

Sorry to bug you, as I know it has been mentioned that this feature
will arrive at some point. Is there any road map or expected time when
this might be?

Also, are you expecting control for these including read / write
access and webhooks ?

Thanks in advance and sorry for the winge.

[Edward Ocampo-Gooding]

Hi tarwin,

Sorry to be the bearer of boring news, but that API is still under development with no ETA.

[tarwin]

Thanks Edward. Are there any plans on ways to apply discount codes to
shopping carts through an API / URL call ?

[wik]

I guess something like Mechanize[1] would do the trick here, but +1 for this in shopping cart or even automagically for volume based discount codes :)

Thanks.

1: http://mechanize.rubyforge.org/

[Edward Ocampo-Gooding]

*puts fingers in ears*

la la la la la la I can’t hear you using Mechanize and shop accounts to do this crazy thing that is super fragile and liable to break unexpectedly…

[Dave]

Now now Edward...

Turns out only ONCE has it really been necessary to change any of our
Mechanize code to play with Discount Codes... that hardly counts as
super fragile.

On Feb 17, 11:05 pm, Edward Ocampo-Gooding <edw...@shopify.com> wrote:
> *puts fingers in ears*
> la la la la la la I can’t hear you using Mechanize and shop accounts to do
> this crazy thing that is super fragile and liable to break unexpectedly…
>

[tarwin]

Thanks for the Mechanize idea, but I don't think it's a good idea
(stable etc) either.

Thanks,

[Dave]

Mechanize is one of the coolest Internet programs out there. Using it
is never a bad idea. I cannot for the life of me see how you can think
Mechanize is unstable.

The unstable issues with this current pattern only has to do with the
chance that in the future Shopify may/will fix Discount Codes. At that
time, you simply pull your old working code and slap in new code to
take advantage of whatever improvements are made.

How is that a problem?

Just because Shopify can change the way the Admin renders Discount
Codes, and you might have to dick around with a new form element or
two, does not equate with Unstable, Dangerous, Fragile or other
nonsense. That is basic software maintenance.

You have to do what is needed to keep the $$ flowing and the clients
happy.

[Edward Ocampo-Gooding]

No, this is the definition of fragile software: unstable dependencies
that will break unexpectedly.

Without doubt, doing something like this will surprise shop owners
depending on your software at an unknown time during which they will
likely lose money directly or indirectly due to having to deal with
your software failing.

Do not do this unless your client is fully aware of these inevitable
consequences.

[Dave]

Is Shopify unstable? Thought so. If it is "stable" by definition, and
you code up a mechanized interaction with the Admin, by definition
"stable", you should not encounter trouble or disaster.

I understand that your viewpoint is one of App has_many Shops. If an
App relies on Shopify not changing, and has hundreds or thousands of
users, a small change in Shopify Admin could present a problem. But
that is not the issue here.

There are Shops that need this mechanized interaction now (there is no
realistic alternative), and they have needed it going on 12+ months or
however long these Discount Codes have been around. Why the FUD on
that?

If I can actually use Mechanize to break a Shop and cost the shop
owner $$$ in sales, then the Shop owner can certainly do the same.
Hence, it is zero-sum game and it is very very likely a developer will
be way more careful than any Shop owner about dealing with dangerous
aspects of Admin. If the only thing that can come of using Mechanize
is to save a Shop Owner hundreds of hours of manual labour, and to
increase their sales 15, 25 or 50%, we win with mechanized
interaction.

How is it that employing a mechanized interaction to automate mundane
Shop Admin tasks is a bad thing, to be so highly discouraged? Where is
the love of computing? Bringing to life beautiful code that garners
rave reviews from gob-smacked non-engineering Shop owners is
pleasant.

I agree that it is possible to wreak havoc on a system with a
mechanized process. But you can also do wonderful things... and for
that... I am not siding with the cautious crew.

There is no inevitable failure here... it is possible someone could
fail at this, sure... but to not venture into the land of letting
Mechanized processes replace tedious, error prone human interactions
is inevitably going to drag down the good vibes of Shopify too.

I have never heard more "bad" Shopify karma from my clients for
anything other than Discount Codes... the #1 most disliked aspect of
Shop Admin... goes a long way to telling me I am on the right track
here...

Why do they keep on asking me to automate the CRUD of Discount Codes?
Why? Is that such a bad thing?

When faced with having to delete 1000 codes, you have to click 1000
buttons in the admin... is that a nice thing to have to do?

On Feb 27, 9:25 am, Edward Ocampo-Gooding <edw...@shopify.com> wrote:
> No, this is the definition of fragile software: unstable dependencies
> that will break unexpectedly.
>
> Without doubt, doing something like this will surprise shop owners
> depending on your software at an unknown time during which they will
> likely lose money directly or indirectly due to having to deal with
> your software  failing.
>
> Do not do this unless your client is fully aware of these inevitable
> consequences.
>

[Edward Ocampo-Gooding]

wat

[Travis Haynes]

I once wrote an application for a company that used something like Mechanize to automate the process of filling out long forms for printing shipping labels. The app worked perfectly for a couple of years. Then, suddenly, without any warning, the company released a new and improved design that used Flash instead of HTML. My app was broken forever.

You can imagine how badly this damaged my reputation with this company. This app, when it was working, took several hours of work off of their shoulders every single day. Now, suddenly, with it broken, and no way to fix it on top of that, they essentially blamed me for having to put in all that extra work, since it was the app I wrote for them that stopped working.

It's never a good idea to provide a 3rd party with the ability to break your application. Period. Don't do it. You're best off just waiting until Shopify implements this in their API, rather than risking having your name turn into mud with all your existing customers using your app if/when it breaks.

[Dave]

A reputation is made over the course of a lifetime. If you never fail
in your life, you live a charmed life. Embrace your failures and learn
from them. I cannot possibly know what damage your reputation suffered
from what was obviously a pretty traumatic experience for you... but
seriously man... tinkering with Mechanize gets your shorts in a knot?
That's like a carpenter not wanted to use an electric circular saw
because he prefers to cut on the pencil line with a hand saw, and
insists that is safer and makes for better work.

[Aaron McLeod]

I think really it comes down to:

being aware of the risks with what you wish to accomplish, and decide if it's worth it to you.

-- 
Aaron McLeod
http://agmprojects.com

[Travis Haynes]

Haha. Wow. I was just sharing my personal experience with this sort of thing, thinking you could learn from my mistake, instead of blindly repeating it yourself.

By the way, I spent my first 6 years after high school working as a finish carpenter, and some times using a hand saw really is the safest, cleanest way to get the job done. Those circular saws can be pretty scary. I've seen fingers chopped off with those things because of people trying to use them for something they weren't designed for. Ask them after they lost a finger if it was worth the extra time saved.

I just hope you walk away with all ten fingers after this job. :)

[Dave]

Travis... I was writing code in assembly language in 1978. I would
wager a beer or two that I have made and learned from more mistakes in
my lifetime than a lot of people trying out computing as a career
option. I also successfully completed a university degree in computer
engineering in the 1980's as I liked computing so much. I am glad you
understood my analogy and of course, I appreciate the act of trying to
pass on your experiences, good or bad.

Right tool for the job I always say, and the wisdom needed to go there
is not always obvious. Glad you made through elementary carpentry with
all your digits intact! Witnessing a power-tool accident as you had to
must be truly gross and depressing.

At least with computing your chances of anguish are reduced to mental
ones and not so much physical ones! Stay healthy and watch out for
crazies with power tools!

[L Creek]

Edward...

I have to ask exactly WHAT it will take to at least make this enough of a priority to offer an ETA? This has to be the single most requested feature going on, what, a year now maybe. And there isn't even a proposed timeline? That is insane, and a bit infuriating.


I honestly cannot see how adding the basic functionality YOU ALREADY HAVE in the product (the ability to created/modify simple coupons) should take YEARS to add to the API. My guess is that you guys are adding all kinds of advanced functionality to coupons, which I am sure will be great. However we have NOTHING right now. Wouldn't it make more sense to do the basics FIRST, and THEN work on the extra functionality? Seriously, couldn't an API version of the exact same coupon ability in the admin panel be done in weeks? If there is some grand technical challenge to it, then maybe share that with the group so we stop hounding you. But if not- you guys have this totally bass-akwards- making everyone who only needs the ability to create a coupon on the fly and modify the expiration date have to wait for god knows what else you are adding.

I think after this amount of time, after the numbers of postings asking for it, and after the repeated stonewalling, you guys should honestly answer why there isn't even an ETA for it. Better yet, answer why it takes so long to simply expose existing functionality to the API. I hope you take the time to finally answer that question...

[Yan Sarazin]

If their plan is in fact to revamp the coupon system, how does it make sense to devote time and resources to build an API for something that will change anyway?

If Shopify does answer you beyond "not ETA yet", would you be so kind as to email Apple and ask them the exact date we can expect the iPad 3 to be released? I'd like to get a lead on the store lines. Thanks.

[Edward Ocampo-Gooding]

Hey there,

Thanks for the allcaps; IT’S GREAT TO SEE THAT FOLKS ARE AS EXCITED ABOUT THIS FEATURE AS I AM!

Seriously though, the situation has been that the way discounts and checkout have been implemented internally have been in a pretty constant state of flux for the last few years. Because we really don’t want to be messing with an API once it’s been released, we’ve been holding off until things settle. Giving out an ETA or timeline that we can’t be sure of is more damaging than otherwise, so we’ve been holding off.

It sucks, I know – imagine being the developer advocate who has watched app deals slip through his fingers for awesome stuff like price optimization engines, post-purchase social stuff, gift cards, etc. Trust me; I’m super stoked for this feature to go public, but until we’ve got it figured out ourselves internally, we’re not confident enough in the API that you’re going to have to trust for your own customers to rely on.

Edward Ocampo-Gooding
Developer Advocate, Shopify

[L Creek]

Edward, thanks for the reply.

Yan S, if you can’t see the difference between a coder asking about a system they use to build apps on and the next release of a consumer product, perhaps you can take your snarky insipid comments somewhere else. (I am sure there is a Justin Bieber fan blog out there that would love your level of insight and brilliance). “Thanks”.

Edward, I understand what you are saying, but here is my plea.

Either we are close to those issues being resolved, or we are not. If we are close, then some rough ETA would be appropriate. If not, then I would suggest a very simple bridge solution. I know- to borrow Yan’s narrow line of thought, “how does it make sense to devote time and resources to build an API for something that will change anyway?”.  Easy- because right now there is NO work around. There is a ton of functionality just waiting to go, once we have codes... ANY kind of codes.

So, if the timeframe is long, here is, I think, a simple bridge solution.

Let the API create coupons EXACTLY the same way as the web form does. No more, no less. Same fields. Same functionality in the cart. The only thing that changes is that the info is coming in from the API instead of via the web form. This would require NO changes to the the cart’s functionality. All it would require is to set up a catching page for the API, to collect and pass the same variables as from the web form to the system.

If we could also use the API to also change the expiration date, that would allow us to create and then inactivate coupons via the API.

That is it- two simple API functions that require no changes to the underlying cart software. I cannot believe that could take more than a week to implement (since there are no database or core program changes to implement). Then we developers would have an option and could start building out the rest of that wonderful technology to enhance Shopify (which, in addition to the uses you mentioned also include mobile coupons, Groupon-like daily deals, loyalty reward programs, affiliate couponing and a whole host of other ideas).

You spend a tiny amount of resources (given what is being spent on the final solution) and then you present this option for exactly what it is- a temporary solution. Maybe the whole thing goes away when the final solution goes live, and every developer will have to ask themselves if it makes sense to put this in their product (knowing a forced rewrite will have to be done once the final solution is released). But at least then the developer has a choice and can make an educated decision. Some (like me) would jump at the chance to add that basic functionality right now (and start selling it) even if I know full well that in 6 months or a year, I’ll have to rewrite it. Others (like Yan S) won’t. But at least we won’t be bugging you guys about getting your full rewrite out.

To borrow a phrase currently used in political debates, don’t make the perfect the enemy of the good. An API that does exactly what the web form does now should be a piece of cake to set up- and opens the door to a lot of new functionality- it isn’t perfect, but for many, it is more than good enough. But right now, you are holding us all hostage, waiting indefinitely, for a complete rewrite. And if that is another year off, then why not give us something to provide at least minimal functionality during the meantime.

I’ve seen the types of coders you have building apps for you. I know what they can do with that functionality and how much they can improve the Shopify product if just given the chance. So do that. Commit to exposing the current functionality as a bridge solution. All it takes is deciding “we are taking too long on this, let’s give them an interim Plan B”, and writing a super simple API page. There HAS to be a way to make that happen.

[Edward Ocampo-Gooding]

Yep, you’re totally right. In fact, we’ve (internally) built a number of implementations for this API. We even wrote this awesome sandboxed Node.js-based thing where you fed it Javascript and write your own Turing-complete discount engine.

I want this too but we can’t have it yet.

I’m really sorry, but I’ve got to close this discussion as we can’t get further than this without me having at least a beta API in my hands for you to test. Believe me when I say that when that comes out, you’ll be the first to play with it.