Solved Interfacing with Gumroad's API

@orestiskon I use the GumRoad API and their License Key System for all my plugins. Here is a quick overview of how you would implement it.

• Enable the license key generation for your product in your gumroad store. This sends the user a key when they purchase
• You then need to implement a way for your users to input that key into their plugins. I have a plugin manager that gives users one location to do this for all of my plugins I sell.
• In your plugin you then call the GumRoad API license endpoint and pass in the Key that the user received.
• The API then returns if the key is valid and how many times it has been used. Each time the endpoint is called you can choose to increase this "used" counter.
• If it has never been used then you then need to generate an offline key that you will store on the users machine somewhere, or in their preferences. This Key would be something like an MD5 Hash of their Cinema 4D User ID, Email Address or System ID combined with some secret key and an identifier for your plugin. UserID+SecretKey+PluginModuleID
• When the user restarts C4D your plugin then looks for this offline key and if found your plugin would run.

The biggest problem with this solution is when users changes machine or move to a new version of C4D. If they haven't backed up their offline key, or if it is not even accessible to them then your GumRoad API key is no longer userful to them.

To remedy this I also have an AWS API that gets called by GumRoad when the purchase. You can add a Callback in your GumRoad account for this. I then call my own AWS API to handle allowing users to re-install the plugins if the GumRoad key has already been used by checking my own API database. Having my own database allows me to reset they keys on my side (something GumRoad doesn't let you do, but I have requested this already from them, ie the ability to reset the Used counter back to zero would do the same thing). But having my own API future proofs me in the event that I wish to move away from GumRoad as well, since I have now essentially built my own licensing system on AWS and may in future remove my dependence on the GumRoad license key generation completely.

I have contemplated providing a monthly service to developers to give them a proper licensing solution for C4D development. But there is really no market for it. There are not enough developers and we are all just wanting to do our own thing for the fun of it mostly anyway.

MAXON really need to sort this out and have an internal system for us developers. It is absolutely insane that they removed the existing system without implementing a replacement. Forcing every developer to roll their own licensing system is a complete waste of time and does away with what the developer wants to do in the first place, which is make a C4D plugin, not spend months investigating and writing their online licensing system.

@kbar Hey Kent, thanks for the tips, some great information there.
Good timing as well, I just managed to interface with Gumroad and test it a first license key.
I used "requests" module for Python, even though I'm not sure it's the best fit, since it requires 4 other libraries to be copied with it.
Maybe pycurl is better for this?
There's also pygumroad but I'm not sure if it will work.

About the offline key, could you elaborate how it's being used?
Edit: Nevermind, I think I got how you meant it. The gumroad confirmation allows the creation of the key.

Having your own database is probably the best, but developing an AWS Database for my first little plugin seems a bit disproportional. Actually I was interested if there was a seller like Gumroad for C4D Plugins that would take care of the licensing for me, but I don't think there is something like that. I was surprised by the learning gap between developing a plugin and protecting it, and wondered how others are handling this. But other than bigger companies like Redshift and Insydium, I can't think of many "indie" protected plugins, so I'm afraid I agree there's probably not a big market for it. But it's so much effort to get there, no wonder there aren't many people developing. It's kind of a feedback loop.

@orestiskon said in Interfacing with Gumroad's API:

Edit: Nevermind, I think I got how you meant it. The gumroad confirmation allows the creation of the key.

Yes that is what I meant.

But it's so much effort to get there, no wonder there aren't many people developing. It's kind of a feedback loop.

So many developers have left already. Especially on the C++ side. It has been made so difficult now that it is simply not worth it for many. C++ devs that sell plugins are a dying breed. I don't imagine there will be any soon except for the big boys and a couple of us old timers. For small, or indie developers, plugin development does not pay for itself. You have to do it just for the fun of it or for the desire to help people out.

@kbar Hey Kent, I have one more additional question:

You mentioned the issue with Gumroad keys is you cannot reset them, so you use the AWS database. But if you want to allow users to install it at another machine, couldn't you also allow generating the offline key beyond gumroad's first use? What is the difference?

Progress.

After some advice that this is possible in native python, I managed to have it interface with Gumroad without extra modules.
If anyone else needs to go in that route, here is a script that does it in Python 3:

import c4d
import json
from urllib import request, parse

# Main function
def main():
    url = 'https://api.gumroad.com/v2/licenses/verify'
    licenseKey = 'XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX'
    permalink = 'XxXXx'
    data = {'product_permalink': permalink , 'license_key': licenseKey}

    data = parse.urlencode(data).encode()
    req = request.Request(url, data=data)
    resp = request.urlopen(req)

    responseDict = json.loads(resp.read())
    print (responseDict)

# Execute main()
if __name__=='__main__':
    main()

@orestiskon said in Interfacing with Gumroad's API:

@kbar Hey Kent, I have one more additional question:

You mentioned the issue with Gumroad keys is you cannot reset them, so you use the AWS database. But if you want to allow users to install it at another machine, couldn't you also allow generating the offline key beyond gumroad's first use? What is the difference?

That’s up to you to allow using it multiple times. But if you don’t limit it then they can post their key online and then everyone can use it, making your product free essentially.

Their license key system is perfect for subscriptions. But for single install software you have to create a system that works for you.

I just use my AWS system as a way to let me reset a license so a user can use the key again.

Or if you write out an offline key to disk then that user could copy it to their second computer manually. I did this for a while but it caused too many support tickets. So instead I limited it and if anyone wants a reset they just contact me.

I noticed the above code didn't work in R21 because urllib changed in Python 3.
The following topic has information on how to handle it:
https://plugincafe.maxon.net/topic/12759/python-3-7-7-will-be-in-the-next-release-of-cinema-4d/5?_=1626131288989

Thanks, guys, for providing hints and getting this discussion moving forward.

Although I see the point on @orestiskon saying in Interfacing with Gumroad's API:

I was surprised by the learning gap between developing a plugin and protecting it

I also think that what Gumroad offers is beyond the scope of the Cinema 4D API improvement. Offering a Maxon marketplace for freelance developers willing to get bucks out of their plugins it's something that might be interesting to discuss on a strategic level, but we can't for sure contain in the C4D API development roadmap.
However, I'll be glad to report to Product Management and eventually get the discussion moved on other tables.

At the same time, I must partially disagree with @kbar saying in Interfacing with Gumroad's API:

MAXON really need to sort this out and have an internal system for us developers. It is absolutely insane that they removed the existing system without implementing a replacement

The current system, which is more flexible on checking what hardware/entitlement Cinema 4D is running on and on making the plugin protection mechanism to react accordingly, compared to the previous existing one, is only lacking the ability to have the Maxon Licenses Server serving plugin entitlements to Cinema 4D. While this was handy to offer a floating-license provisioning mechanism for plugins, it has, imho, little to do with the numbers of little guys doing plugin-development and it covers only a fraction of a whole licensing-managing system that goes from selling the licenses to check the license in the host application.

Cheers, Riccardo

@r_gigante said in Interfacing with Gumroad's API:

The current system, which is more flexible on checking what hardware/entitlement Cinema 4D is running on and on making the plugin protection mechanism to react accordingly, compared to the previous existing one, is only lacking the ability to have the Maxon Licenses Server serving plugin entitlements to Cinema 4D. While this was handy to offer a floating-license provisioning mechanism for plugins, it has, imho, little to do with the numbers of little guys doing plugin-development and it covers only a fraction of a whole licensing-managing system that goes from selling the licenses to check the license in the host application.

I have to completely disagree here. The previous system had a UI in Cinema 4D to allow users to enter in their License keys for plugins. This was one single place that could be used by a user to enter in the licenses for the plugins they purchased. Now every developer has to implement their own version of this dialog. This leads to a fragmented experience for the user since now every single plugin has its own different way of entering in licenses. And also every developer now has to implement their own version of a license check at startup.

The previous method worked very well for the causal developer who did not want to make an online system. I was pretty shocked when you removed it without any plan for a replacement.

Your current system does work well for you at MAXON. IE the entitlement and licensing system that C4D uses.But that is totally irrelevant to external plugin developers.

@r_gigante The reason I'm going with Gumroad is because it provides a system that I can automate as an indie developer. I can make useful C4D tools and plugins, but I'm not a web developer nor a fully-fledged programmer.

The current license system in Cinema 4D implies that the user generates License Information and sends it to the plugin developer to get get a personalized key back.
I could do this either by hand via emails, or by implementing an automated system on a website with an online software that does that.

The first option is a horrible ux experience for the user and a huge overhead for the developer, so it's an invalid option.
The second option requires me to become a full-blown web developer to make a simple c4d plugin, requiring completely disproportional amount of effort.

Therefore yes, I would argue having to develop our own license systems is a very big reason why c4d developers are so few.

Maxon implemented a new license system with 21, which would be great for plugins if they could use it. I.e. every plugin license to be added to the MyMaxon account, and let the maxon licensing system do the licensing. But this is not how we can use it.

Not only that but there are some very big limitations currently. If a studio account has 20 c4d licenses, I can't tie the plugin to a specific c4d version as I would with the serial numbers. I can only tie it to 1 machine, which is limiting and uncomfortable for the customer, or tie it to the account and allow them to only get 1 plugin license and use it in 20 different c4d licenses simultaneously.

In the end I see redshift have it's own license server, x-particles having their own licensing system, and the indie plugin developers having no idea what to do and how to do it.

Either way the licensing system has a lot of room for improvement. Currently it doesn't seem to be made with the plugin developers in mind; especially indie developers are struggling with it, as I've noticed in numerous people I talked with.

@orestiskon said in Interfacing with Gumroad's API:

The reason I'm going with Gumroad is because it provides a system that I can automate as an indie developer. I can make useful C4D tools and plugins, but I'm not a web developer nor a fully-fledged programmer.

This is the exact same reason I chose GumRoad. It at least allows for a way for a customer to license their plugin without having to extract a Json file from C4D and send that, or parts of that, to the developer. Which the developer then needs to process somehow or handle by hand. It leads to too much confusion and support tickets.

The GumRoad check allows for a hands off licensing approach. I have virtually zero support tickets now.

@r_gigante This not about MAXON making an online store, marketplace or anything like that. It is purely about licensing. Something that MAXON should provide a solution for.

It can be solved with an C4D SDK solution and a simple backend API.

The problem is that no one at MAXON is an external plugin developer trying to sell plugins. So you have never hit these pain point. I have extensive experience with many different online sales platforms now, all in the search for something “simple” that would work with C4D due to the removal of the previous system.

Knowing how online sales systems work and how they can be connected is the knowledge required to be able to understand how an external developer would license the plugins in an automated way. A way to produce a license key that can then be checked by the plugin. This can all be automated. A solution from MAXON can 100% be made that would work for all online stores. I previously talked about this with Rick and Paul when R21 left all developers in the lurch and out on their own. But it seems like there is no interest in this and no budget. I even offered to provide a solution. But I can’t sell that to developers, it should really be done by MAXON.

You could also use your new system and allow developers the ability to lock licenses that way, ie with separate licenses or entitlements and control over seats and orgs etc… But I also have very in-depth knowledge of that system as well and understand how messy that could get. So I think an alternative licensing system built just for the use by external plugin developers would be a good solution.

Thanks for the feedback.

With regard to @orestiskon saying in Interfacing with Gumroad's API:

The current license system in Cinema 4D implies that the user generates License Information and sends it to the plugin developer to get get a personalized key back.

please consider that a similar mechanism was in place even before R21 to let the plugin vendor generating the plugin license based on this customer information (see Licensing Plugins – Part I – Basics). So the UX is as much as was in the past and everybody is free to judge it.

With regard to @orestiskon saying in Interfacing with Gumroad's API:

Not only that but there are some very big limitations currently. If a studio account has 20 c4d licenses, I can't tie the plugin to a specific c4d version as I would with the serial numbers. I can only tie it to 1 machine, which is limiting and uncomfortable for the customer, or tie it to the account and allow them to only get 1 plugin license and use it in 20 different c4d licenses simultaneously.

it's not right, as proved in the Basic Licenses Workflow examples (blw_common, blw_pluginlicensedialog, blw_simplegenerator) where you can bind your license mixing up the following settings:

• user ID
• system ID
• binary type (Cinema or TR)
• binary version
• c4d licensing type (nodelocked or floating)
  and easily cover the case pointed above.

Wtih regard to @orestiskon sayng in Interfacing with Gumroad's API:

especially indie developers are struggling with it, as I've noticed in numerous people I talked with.

as far as I can see in this forum, I can count only 5 threads (including this) in the last 2 years. Please let your contact use the forum if the need support.

In the end I don't think that having still in place the old system would have helped on solving the issues reported here because that previous system was not addressing the issues that with Gumroad API you can address (like billing, license key generation and so on).
Nonetheless I'll ask PM to check again this topic and see if there's space in the future to accomodate with helpers eventually streamlining the plugin licensing process.

Thanks @r_gigante for the feedback. I can't really comment from experience about the previous system, as I haven't developed a plugin for it.

I would be interested however to know how would you propose to solve the example I gave.
When I was inquiring about this case when the new licensing was introduced, I couldn't find any solution either.

We want to fulfill two requirements:

1. Provide a floating plugin license that can be installed in as many machines as the user wants.

2. If they have 20 c4d licenses and they bought 3 plugin licenses, they should be able to use it with 3 out of their 20 cinema 4d licenses.

It's pretty common case, I would guess many if not most plugins would have similar requirements.

I can solve the 1st case by tying the plugin to the User ID.
I can solve the 2nd case by tying the plugin to the machine ID but that breaks the 1st case.
I don't think any of the other information such as binary type, binary version or c4d licensing type is helping with the above. I would expect to use a Cinema 4D License ID but I don't believe it exists.

@r_gigante This is how the user experience for the previous system went.

1. Copy the last 11 digits of the serial number and paste that on the developers website.
2. They then receive a key which they can then paste into the Help->Personalize dialog of C4D. Done!

• Now there is no standard whatsoever for the user.
• Now there is no dialog where users would even paste in all their license keys.
• To get the information required you have to ask the user to actually start C4D and go to a menu, save out an json file, open that file and find something from it then paste that into the website, BUT there is absolutely no way to check that they have pasted the right thing since there is absolutely no convention to what the format of that data is or should look like. This also ignores the fact that a lot of the time it is not the end user that is purchasing.
• Now even if the user did send the right information, and they did manage to get back a license key, they now have to find the custom location that the developer has specified to actually enter this key. IE there is no longer a standard way.
• And the two points that Orestis mentioned are now longer possible either unless you implement your own custom solution.

Because of all this mess myself and other developers are instead moving to an online system of our own creation in order to avoid anything to do with touching C4D (pre-purchase) at all for this process. Hence the use of GumRoad APIs just to check if a user has a valid license. Or if you have the time and money you would create an online activation system instead against your own customer database (ie 10Duke or a custom solution). Neither of these are solutions for a beginner.

The reason you are not seeing many tickets is because it is now such a damn waste of time, why would anyone bother. So all the indie developers will either not use licensing at all, which is actually the easiest way to go, not release anything, or just leave for another platform like Blender. Looking at the number of tickets is an example of Survivorship Bias.

Maxon has the opportunity to build a world class plugin echo system but continues to ignore vital aspects of how a plugin developer would actually work with customers. You have this incredible SDK Team here doing an amazing job, yourself included, but there is no one out the back thinking about the UX for customers and 3rd Party developers. It is because of this that the plugin market for C4D has continued to shrink. There is no thriving market.

As a side note, it wasn't until I left Maxon and started selling my own plugins that I became aware of these issues. You do not see the issues unless you step outside the bubble and start looking at how a 3rdParty dev would actually sell in real life, and how you would create something with the least friction for the customer as well as create zero support tickets for yourself. You need to go through the pain before you see the problems. And R21 was a huge pain. Months of pain trying to figure out how to do licensing all over again with zero info available.

Right now it is incredibly hard and obfuscated. Where it could be a beautifully crafted experience for the end user and the developer. It would also be a great selling point for Maxon if they spent time actually making a proper solution.

Just one last comment on this licensing issue.

I have a video that tells users how to install and license my own plugins for R21 upwards.

It has been viewed 33,882 times as of today. It is my most watched video every month.

https://youtu.be/WV3M8_I3Ovw

I don’t have that many customers or sales.

These views are from regular C4D users using Google to figure out what to do now since the old way is gone.