1. The temporary token should be run-
1. The temporary token should be run-bound, only work for the duration of the run. If you can use it 1 hour after the run, that would be quite a huge security bug so please report that if it actually happens.
2. Not sure about ToS, it definitely looks a bit shady. But practically it sounds ok, for PPR/PPE, the compute/proxies/storage costs for the token are subtracted from your PPE revenue so the customer wouldn't really care what you do with it. For PPU however, you could just abuse the token for your stuff. The delay between your server and Apify should be tens of ms (if you are in the US) so I would really go with relaying everything back to the Actor.
3. What is the reason to use your server, are you hitting any bottlenecks?
2 Replies
1. I’d prefer to send you a private message.
2. It’s PPE, so I’ll send the data back to the actor run and let it use the token inside the run. My initial idea was to charge first (from the run) and then immediately send the results from my server. That way, if the user aborted after being charged but before results were sent, a webhook would notify my API, and my server could query the run endpoint to check how much was charged and how many results/pages were sent. If the numbers didn’t match, the server would complete the upload to keep everything consistent. But now I’ll simply send the data directly from the run instead.
3. My strategy is to focus on Apify as my main sales channel, but I want to design my backend to be platform-agnostic. This gives me the flexibility to integrate other platforms in the future. Additionally, for code security and secret management reasons, I prefer to keep the scraping logic and sensitive variables on my own server. In the long run, this approach also gives me full control over infrastructure costs and scalability.
Yeah, that makes sense if you don't mind the extra effort in maintaining your infra. Is there something Actors could do better for you?