Keeping customers record, is this allowed on envato?

[ichiegroup]

@baileyherbert

Here is a new modified approach I want to adopt. Instead of issuing license key, I can make modifications on our server to use envato purchase code instead of license key for our products that would be sold on code cayon.

Below is my follow up message to support;

Hi Oliver,

Thank you for your clarification.

Can you further check this out for me.

So far we have established that,

2. Does Envato allow authors to keep records of domains and server IP where their products purchased on code canyon are being used?

Yes, this is allowed.

With this, can I implement a system like this,

1. During the installation of the script, the customer would be required to enter the purchase code which we will validate using the envato API.

2. If the purchase code is valid, we will alllow the users to go ahead with the installation, else the installation won’t complete.

3. After the installation is complete, the script would a send a request to our server with the following information;
   a. Domain name where the script was installed
   b. The server IP
   c. Purchase code

These parameters would be securely stored on our own server. and the purchase code saved on the installed script.

4. We will periodically check for suspended or blocked purchase codes using the envato API against the record we currently have.

5. Some features requires external calls to our First Party API like currency conversion API, blogscrapper API, etc.

6. When the script makes a request to our API, we will check if their purchase code is still valid or not. If valid, the user would be granted access to the converter, else he would be denied.

Thus we can modify our server validations for APIs to also use purchase codes instead of our standard issued API/License Key

Would this be allowed by Envato?

I will update this thread as soon as i get a response.

Also, I understand that Envato allows support through external url, since we use a ticketing system that requires users to create an account, would Envato allow it?

[baileyherbert]

@ichiegroup

After the installation is complete, the script would a send a request to our server with the following information;
a. Domain name where the script was installed
b. The server IP
c. Purchase code

I would personally advise responding with some sort of access token generated on your side. Using the purchase code itself as the API key isn’t advisable as you wouldn’t be able to deactivate specific installations or rotate it if compromised.

Example scenario:

A purchase code is somehow leaked onto the internet. Now pirates have instant access to your API. By disabling the purchase code itself, you’re punishing the real buyer who almost certainly didn’t leak it intentionally.

A better solution – allocate an access token after the purchase code is provided and disable the purchase code from being used to generate further tokens. If the buyer reinstalls the application, they can either contact you to deregister the purchase code, or you can provide an automated form for this using OAuth like most authors do.

In this case, you won’t store the purchase code within the application, but rather the access token. If this access token leaks, you can work with the buyer to generate a new one. If the purchase code leaks, you have a mechanism in place to fight it without harming the original installation.

@ichiegroup

• We will periodically check for suspended or blocked purchase codes using the envato API against the record we currently have.

I don’t recommend this approach. If an account is ever suspended or deleted for any reason (even if the corresponding license of your item is still valid) the purchase code will start returning a 404. I’ve encountered this a few times with my own buyers, so I only perform such suspensions manually.

It might be worth following up with support regarding this afterwards to see what they suggest, but I’ve taken the passive and careful approach for myself to avoid any false positives.

@ichiegroup

4. When the script makes a request to our API, we will check if their purchase code is still valid or not. If valid, the user would be granted access to the converter, else he would be denied.

Definitely don’t validate the purchase code for each request. Someone on the forums did this recently and was curious why they were being rate limited. Validating the purchase code one time is sufficient unless checking for support renewals.

It’s also crazy inefficient to spam the API with repeated purchase code checks to monitor for an event (sale reversals) which will realistically only occur a small number of times. I highly recommend the manual approach instead. You can monitor for sale reversals on your statement with the API too, but can only see the associated purchase codes from the actual statement page on codecanyon.net.

@ichiegroup

Also, I understand that Envato allows support through external url, since we use a ticketing system that requires users to create an account, would Envato allow it?

Yes, this is common. The registration form for your support area should ask for a purchase code, and you can re-check the purchase code whenever they submit tickets to confirm the support period if you’d like. Just be mindful about the fields on your registration form. Name, email, and purchase code should be sufficient (as well as a password for login, I suppose).

Edit: Or you can use OAuth to add a “Sign in with Envato” button to your support website, at which point you can easily and automatically get their username, email address, and purchase code(s).

[ichiegroup]

@baileyherbert

I would personally advise responding with some sort of access token generated on your side. Using the purchase code itself as the API key isn’t advisable as you wouldn’t be able to deactivate specific installations or rotate it if compromised.

This is example of what we actually currently have now.
Example, user enters their purchase code and if it validates, a bearer token is issued to that would be used for validating request sent to our server.

But envato stated that they don’t allow any of it.

1. Does Envato allow third-party license keys or tokens in place of purchase codes?

No, we don’t. In short, we do not allow encryption as such within the items, and any item must work “out of the box.”

As you mentioned, we have an API which you can use https://build.envato.com/ to add verification checks, e.g., if a user has a valid purchase code which we provide when a user purchases your item.
We are also on hand should you ever discover an end-user misusing an item regarding their license terms.

Maybe instead of having users create account, we can just add the activation during installation and validate via GET request.

@baileyherbert

I don’t recommend this approach. If an account is ever suspended or deleted for any reason (even if the corresponding license of your item is still valid) the purchase code will start returning a 404. I’ve encountered this a few times with my own buyers, so I only perform such suspensions manually.

It might be worth following up with support regarding this afterwards to see what they suggest, but I’ve taken the passive and careful approach for myself to avoid any false positives.

Thanks, never consider this. The manual method would work. We have also implemented a way for change domain. eg. you can activate for dev.domain.com and later want to change to domain.com in production, or migration.

@baileyherbert

Definitely don’t validate the purchase code for each request. Someone on the forums did this recently and was curious why they were being rate limited. Validating the purchase code one time is sufficient unless checking for support renewals

This was what intend;
After installation, we save purchase code on our server with a status (e.g status ‘active’, ‘suspended’, ), and next validate time (e.g next_validate_time ‘1663634504’).

Using cron job service on our server, when the next_validate_time <= time(), we send a request to envato to check if the purchase is still valid, if let’s say it no longer valid, we will update the status from ‘active’ to ‘suspended’.

Then we script makes a request to our server, will check the current status againts our record not sending the request directly to envato.

@baileyherbert

Yes, this is common. The registration form for your support area should ask for a purchase code, and you can re-check the purchase code whenever they submit tickets to confirm the support period if you’d like. Just be mindful about the fields on your registration form. Name, email, and purchase code should be sufficient (as well as a password for login, I suppose).

Edit: Or you can use OAuth to add a “Sign in with Envato” button to your support website, at which point you can easily and automatically get their username, email address, and purchase code(s).

Yeah, this okay.

[baileyherbert]

@ichiegroup

But envato stated that they don’t allow any of it.

I’m not disagreeing with what support said, but I do think their response to that particular question was a bit ambiguous and incomplete.

This is what’s not allowed per their message:

• Forcing users to register on your website and then providing them with your own activation code (I believe this is how they interpreted your inquiry).
• Encrypting the item in any way to facilitate or protect this activation process.

What Envato wants to see is that your purchase code is the sole key used for product activation.

In the process I described above, this is true. Look at it from the buyer’s perspective: they enter their purchase code, and the product is activated. The access token is entirely behind-the-scenes and the buyer will never interact with it in any way.

If unsure, I would recommend writing back asking for clarification, but there’s really no other way to implement such a system. Every item out there that ties licenses to domains does it this way.

@ichiegroup

Thanks, never consider this. The manual method would work. We have also implemented a way for change domain. eg. you can activate for dev.domain.com and later want to change to domain.com in production, or migration.

That’s great! Something else to keep in mind is that some buyers (especially developers) may install two copies at once – one for development/staging and one for production. Make sure you have a way to cater to them, because these two installations are technically still one “end product” and thus are within the license terms.

@ichiegroup

Using cron job service on our server, when the next_validate_time <= time(), we send a request to envato to check if the purchase is still valid, if let’s say it no longer valid, we will update the status from ‘active’ to ‘suspended’.

I still do strongly recommend skipping this step and instead deferring to your manual deactivation process to avoid any false positives, but ultimately it’s your choice. If you do end up following through on this, please be careful about your implementation so that any connection or server-side errors from the API won’t accidentally deactivate everyone’s licenses

[baileyherbert]

Sorry, I missed this part in my response:

@ichiegroup

Maybe instead of having users create account, we can just add the activation during installation and validate via GET request.

Yes, this is definitely the correct approach (mixed in with the access token system of course!) – make your installation as seamless as possible.

Your script’s installer can ask for their purchase code on the spot, and then can communicate with your own API to negotiate an access token for further communication. That’s the exact process I’ve used here since 2013.

[ichiegroup]

@baileyherbert

I’m not disagreeing with what support said, but I do think their response to that particular question was a bit ambiguous and incomplete.

This is what’s not allowed per their message:

• Forcing users to register on your website and then providing them with your own activation code (I believe this is how they interpreted your inquiry).
• Encrypting the item in any way to facilitate or protect this activation process.

I will write to them after they have responded to my follow up.

@baileyherbert

That’s great! Something else to keep in mind is that some buyers (especially developers) may install two copies at once – one for development/staging and one for production. Make sure you have a way to cater to them, because these two installations are technically still one “end product” and thus are within the license terms.

Thank you for bringing this to my attension. Allowing sub directory installation should solve this. User A activates on dev.com , automatically, subdomains.dev.com should be whitelisted as well.

@baileyherbert

I still do strongly recommend skipping this step and instead deferring to your manual deactivation process to avoid any false positives, but ultimately it’s your choice. If you do end up following through on this, please be careful about your implementation so that any connection or server-side errors from the API won’t accidentally deactivate everyone’s licenses

Nah, I’m going with the manual method you suggested. Was just explaining what I meant initially.

Here is another question that I have;

If User A purchases and activates dev.com, User B steals User A’s purchase code and username and wants to change dev.com to his-own.com. How would I be able to verify that User A is not the one making the request since User A activated dev.com without creating an account?

[baileyherbert]

@ichiegroup

If User A purchases and activates dev.com , User B steals User A 's purchase and username wants chnage dev.com to his-own.com . How would I be able to verify that User A is not the one making the request since User A activated dev.com without creating account ?

I’m assuming you’re going to have some sort of form on your website to automate this process? If so then the best approach I’ve found is to use OAuth with the Envato API and have the buyer log in with their Envato account to confirm their identity.

That’s how I’ve done it since 2016 and haven’t had any issues. Buyers can log in with their Envato account and manage all of their purchases from one screen and deregister specific installations with a click.

If you’re building your own support website, I would generally advise using OAuth rather than purchase codes for the same reasons. I myself operate strictly over the contact form on my profile, which immediately verifies the identity of each buyer for me.

[ichiegroup]

@baileyherbert

I’m assuming you’re going to have some sort of form on your website to automate this process? If so then the best approach I’ve found is to use OAuth with the Envato API and have the buyer log in with their Envato account to confirm their identity.

Thank you so much, you have been really helpful.

[ichiegroup]

@baileyherbert @charlie4282

here is the response from envato

Hi there

I want to confirm that your implementation would be ok
I think it’s important that we make the following clear:

Whilst we allow authors to offer support externally via their own support systems, any personal data will be the responsibility of the author to ensure it meets with local laws.
As long as they are using our API

I hope this can add clarity to your concerns.

[ichiegroup]

@baileyherbert @charlie4282

Quick Question please.

My project allows ‘theme change’ . We have added in the documentation on how to create a new custom theme if the customer wants.

E.g You made 4 purchases for the script to be used on 4 websites. At the time of purchase, there only 2 themes included by default. Now you don’t want all your four websites to have same design and you don’t want to loose your customization after update.

We have included a web code editor for adding custom js and CSS (stored in the dB) that would be retained after update.

However for complex changes that would require html elements, you can simply create your own custom theme following our documentation where you can customise as much as you can.

To my question:

• Can I invite other authors to create their own themes and sale independently on evanto.
• I have other coders that are not envato author, can I invite them to create their own themes and sale elsewhere considering that I’m an exclusive author?

The product sold on envato is different from the ‘theme’ other authors would create and won’t be treated as the same item as mine but rather as an add-on.

Does envato allow this?

[baileyherbert]

@ichiegroup

• Can I invite other authors to create their own themes and sale independently on evanto.

Yes, other authors can create and sell themes for your item, but they’ll need to upload them into the add-ons category.

@ichiegroup

• I have other coders that are not envato author, can I invite them to create their own themes and sale elsewhere considering that I’m an exclusive author?

So long as you are an exclusive author, I believe this will violate the exclusivity policy. Envato requires add-ons for exclusive items to be sold on their platform because they are all part of the same “product family”.

The only exception is that you can sell such add-ons on your own personal website, but this privilege does not extend to other developers.

[ichiegroup]

Thanks