hey for auto updates that bounce through your server I would avoid the download url and just self host the files. verify their purchase with the purchase code. this is easier because the end user doesn’t have to go and find their API key, just a purchase code
The main reason I was avoiding that is that I’ve been told in the past that serving the files from my own server constituted “distributing the files outside of Envato” and therefore broke the exclusivity agreement (even when authenticated). Seems a bit crazy, but this is why I haven’t previously implemented it. Updating through the Envato download link avoids that issue altogether.
But beyond that, it’s a whole lot of bandwidth for 37,000 customers, plus spikes on the processing load. To be honest, I’m just not 100% sure my current infrastructure will scale to that load, and it’s tough to load test without just trying it out in the wild (which could end very badly).
It seems like downloading straight from Envato should be the path of least resistance.
Do you think redirecting through my site to the Envato download URL would work, and is just more complex – or do you think it’d actually cause issues?
if you’re playing aroung with auto updates can you try and get network plugins updating?
I was looking at that myself, but hadn’t come up with a solution yet. If I figure anything out, I’ll definitely let you know
Thanks, Chris – yeah, I’m using it for a CodeCanyon WordPress plugin.
I appreciate the resource – looked through the code and I’m assuming you’re referring to ‘wp-download’. I will have to test that out and see if it returns anything for a plugin
I’d love to hear from a staff member/dev if that endpoint won’t count toward the download limit. Since the current download count isn’t made public, there’s no real way to tell until I actually hit the limit.
Thanks very much for your input, Gewora and Dave! I really appreciate it
The issue is that I’m hooking into the WordPress update system. So I have an update checker retrieving data from my server, at which point I need to return a link to the download package URL, which WordPress then holds onto until the user actually runs the upgrade.
So do you think if I made that download URL point to my own site, which then queried the Envato API, retrieved the download link, and redirected to it, that that would work? This is something I’d normally just experiment with, but since I’m running up against that limit, I want to maximize what I get out of every test
Hey guys, question about the API:
Using the download-purchase API endpoint (which retrieves a download URL for the user) seems to count toward the file download limit, even if the file is never actually downloaded. I’m wondering if anyone can confirm that, if that is the intended functionality, and what is the best way to avoid hitting that limit.
I’m trying to provide my customers direct access to their plugin download package via the Envato API. I have been testing with a purchase code and API key, and using this endpoint:http://marketplace.envato.com/api/v3/USERNAME/API-KEY/download-purchase:550e8400-e29b-41d4-a716-446655440000.json
The result set looks like this:
This was working great. I only ever actually followed the download URL and downloaded the file once (just to test it was working). After that, I explicitly never downloaded the file, specifically because I knew there were limitations on how many times I could do so.
However, after testing for a while, it suddenly stopped working, and returning a message that the download was not currently available. Checking the Downloads page for that account, I saw the message that I’d exceeded 20 downloads in 24 hours, and the download was temporarily disabled.
I didn’t actually download the file 20 times, but I bet I hit the API requesting a download link 20 times.
So here’s the issue:
It seems that just hitting the purchase-download end point, even without ever downloading the file, counts toward the file limit
So here are my questions:
1. Can anyone confirm this behavior?
My conclusion above, that even if you don’t download the file, it counts toward the download limit – has anyone else experienced this? (Perhaps I’m missing something)
Assuming this is the case:
2. Is this the intended functionality?
I’m wondering if a dev could comment on this and explain whether there is a purpose to counting API queries toward the limit, even if a download doesn’t occur (and, if you query the download-purchase endpoint, and then actually download the file, would that count as 2 downloads toward the limit)?
3. Is the result from the purchase-download endpoint good indefinitely?
Update: as Gewora pointed out, it is a temporary link. Looking at the URL more closely, this should have been apparent to me
Obviously, I can’t provide this code to my customers if it’s going to burn through their download limit, so I’d like to find out what the best way around this is.
I’m wondering if anyone else has run into this previously and might have some insight. I’m going to submit a support ticket as well (since I need to clear that limit anyway), but I’m hoping others who have played with the API more might have some experience with this.
I don’t think you’re getting spam from that demo site. It sounds more like the spam is coming through a contact form on your site, but because you imported the demo content, the email template in Contact Form 7 still has the text “This e-mail was sent from a contact form on Arista (http://demo.qkthemes.com/arista)" in it.
I’ve invited my buyers for beta testing. I’ve demanded their purchase code to participate.
Exactly, this is how I always do it. I generally just post a topic in my support forum (where everyone is already authenticated anyway) asking for beta testers. I create a new forum section just for feedback on the beta. Tends to work pretty well.