⚠️ Apify PPE Pricing Model Chaos
Purpose of this post:
This post is not a feature request or complaint. Its purpose is to seek clarity from the Apify team and invite input from the developer community regarding the confusion around the PPE (Pay Per Event) billing model.
I’d like Apify to clearly state what’s allowed and what’s not allowed when it comes to PPE billing practices, so that developers can align their actors accordingly and avoid policy violations.
Recently, after a discussion with @Saurav Jain , I was informed that my current PPE charging method is considered unfair and against Apify’s policy — and that action might be taken on my actor.
Hence, I’m outlining the key issues here to get clarification, so that:
• PPE billing can be updated correctly, and
• Other developers can learn from this discussion until it’s officially documented and published.
I’ve thoroughly read:
🔗 Apify Docs - Best practices for PPE actors
However, this article only provides recommendations, not clear policies defining what is or isn’t allowed.
@Lukas Krivka @vladdy @Saurav Jain
5 Replies
🧠 1. Memory Scaling
I have been developing actors that can run on memory as low as 1 GB, and the user can choose to run the actor in 2 or 4 GB as well if they want faster execution. The actor also supports thread count as input, and if the user wants to use residential rotating proxy, they can choose to have 4 threads as well. That means memory can be 4 times higher, resulting in 16 GB as well.
So, in summary, the same actor can span any memory from 1 GB to 16 GB. Since Apify charges developers multiple times more when memory grows, it seems logical that users should also be charged proportionally based on memory usage.
💬 Question to Apify:
Is it allowed to charge users a multiplier based on memory usage?
For example:
• A run with 2 GB producing 10 results
• vs a run with 16 GB producing 10 results
→ Apify’s cost is 8× higher, yet the user’s result count is the same.
Currently, I apply a charge multiplier to compensate.
If this practice is not acceptable, please clarify what the expected approach is.
-----------------------------------------------------------
🧩 2. Residential Proxy Usage
I have actors that run fine without a proxy. However, customers need fast scrape output, and to facilitate this, multi-threads are supported. But sites will start blocking multi-threads without a proxy. So, the actor has residential proxy support as well. This serves both types of customers without any problem. Lightweight usage customers don’t prefer to use a proxy, while heavy usage ones will use residential proxies. However, Apify has very significant charges when it comes to residential proxies.
So, the problem is how to bill fairly to a customer for one record event — for those who are using a proxy and those who are not. I have come up with my own solution, where I add a degree of multiplier to charge events when residential proxy is used to solve the problem, and it works fine.
💬 Question to Apify:
Usage of residential proxy causes multi-fold Apify platform charges for the same record being pushed. This usage can be 2x, 5x, or even 10x of scraping the same record without a proxy, depending on the amount of page resources being scraped. What is the suggested approach here? Currently, I am using a charge multiplier for the record when a proxy is used. If this is not allowed, please suggest an alternative.
-------------------------------------------------------------
Hey Dhrumil, thanks for the message we will reply you on working day!
💾 3. Key-Value Store Usage (Incremental Crawling)
Key-value platform usage cost is 12x that of dataset writes. I have scrapers that provide incremental scrapes, and customers love that feature. They come back after 1 week and just get new items added to the target site. This requires access to key-value storage. That means the crawl can run for 1 hour and still find only 10 new items. I can’t solely rely on pay-per-data item delivered here. I will be at a huge loss otherwise.
This also means that a run can last 20 minutes checking 1,000 key values and crawling but may find no new items listed on the target site. However, the customer should be charged for crawling and all the key-value read/write operations to be fair.
💬 Question to Apify:
Please provide the right way to do this. Also, when such key-value checks are involved, the cost of one record is significantly different from that of a normal customer who is not using the incremental update feature. To accommodate both customers, I have added a charge multiplier for the customer who prefers incremental updates and 0 additional charge for the customer who is not using it, to be fair.
Is this an unfair practice? If so, what is Apify expecting as the right way? In this scenario, a customer might get 0 results but still get charged for crawling. Is this against policy?
Currently, Apify is accusing PPE developers of charging customers even without results and mentioning that it’s strongly against it. But this idea of result-based thought process needs to be reviewed by Apify itself when it comes to PPE actors since underlying platform cost is not per result.
------------------------------------------------------------
💰 4. Minimum Commitment
Every software out there these days is asking for a minimum commitment. Let’s say my actor costs 1 USD per 1K records. The cost is 0.001 USD per record. But I don’t want my actor to be used for just 100 records and get paid only 0.01 USD for usage! Is this all the value the software holds? I want customers to pay at least 1 USD in exchange for 1,000 records. That’s a more sensible way of charging.
If you still don’t agree with that, then why does Apify have a starter plan of 39 USD? It’s asking for a minimum commitment from the customer upfront. Although Apify offers platform usage worth 39 USD in the same month in return, which is a perfect sales strategy. So why is it a problem when a developer follows the same approach?
When my actor starts, I am taking 2 USD upfront in exchange for 1,000 records. Then the customer doesn’t pay anything until 1,000 records are scraped. After that, it becomes pay-as-you-go.
💬 Question to Apify:
How is it against Apify policy to charge 2 USD upfront and then allow usage of 1,000 records without any further charge? Like I said, every software out there — including Apify itself — applies a minimum commitment for the usage of software
-------------------------------------------------------------
🧾 Summary & Final Thoughts
If the only acceptable solution is to create separate PPE events for every possible scenario (memory, proxy, storage, etc.), it will lead to an overwhelming list of events, confusing customers even more.
These four examples are just the major pain points — there are many minor ones (like record detail levels, output versions, etc.) which I haven’t included here to keep this post concise.
👉 I’m not requesting new features — I’ve already built custom solutions to address these pain areas. I know nothing happens overnight to solve all the pain points. Eventually we will get there but until that I am using my own layer of work around which is built on top of PPE events.
But I’ve been told that my methods are “not allowed” under Apify policy. It would be extremely helpful if Apify could publish a clear policy document (in addition to “best practices”) specifying: • What developers can do, • What’s strictly prohibited ----------------------------------------------------------- ⚖️ Closing Thoughts The core issue is that PPE simplified billing for Apify customers, but that complexity is now shifted to developers. Developers are expected to: • Simplify event billing, • Absorb variable platform costs (memory, proxy, storage), and • Avoid “unfair” charging practices — even when trying to stay profitable. If Apify continues to enforce a customer-only viewpoint, developers will struggle to survive under PPE. Apify’s pricing model is fair — you pay for what you use — but developers need clarity and flexibility to mirror that logic in PPE billing. If Apify only take customer centric attitude, and threatens developers for unfair practice, how developers would accommodate in this new model ? ---------------------------------------------- ✅ Request: Please, Apify team, provide an official clarification or policy outlining what is and isn’t acceptable for PPE billing, so we can all build confidently and fairly. Thank you for the immediate response. I understand and respect the fact that all these points need to be discussed internally before providing answers.
But I’ve been told that my methods are “not allowed” under Apify policy. It would be extremely helpful if Apify could publish a clear policy document (in addition to “best practices”) specifying: • What developers can do, • What’s strictly prohibited ----------------------------------------------------------- ⚖️ Closing Thoughts The core issue is that PPE simplified billing for Apify customers, but that complexity is now shifted to developers. Developers are expected to: • Simplify event billing, • Absorb variable platform costs (memory, proxy, storage), and • Avoid “unfair” charging practices — even when trying to stay profitable. If Apify continues to enforce a customer-only viewpoint, developers will struggle to survive under PPE. Apify’s pricing model is fair — you pay for what you use — but developers need clarity and flexibility to mirror that logic in PPE billing. If Apify only take customer centric attitude, and threatens developers for unfair practice, how developers would accommodate in this new model ? ---------------------------------------------- ✅ Request: Please, Apify team, provide an official clarification or policy outlining what is and isn’t acceptable for PPE billing, so we can all build confidently and fairly. Thank you for the immediate response. I understand and respect the fact that all these points need to be discussed internally before providing answers.
@Dhrumil just advanced to level 4! Thanks for your contributions! 🎉
Hello @Dhrumil, I don't think we need to talk necessarily in terms of allowed of not allowed. But if your pricing is very different from the rest of Actors and also confusing or not well explained in the readme, we might expect more user issues and more work for our support teams. Because of that we might want to promote your Actors less than we would normally. I believe most of the problems you are trying to solve can be dealt with more "native" approach.
1. For now it is best to just allow only low memory to protect your margins, especially for single URL runs. For large runs, if you run a concurrenct workflow, the memory/CPU should be fully utilized. Soon we will release a "dynamic memory" feature where the memory will be set by yuor function depending on input. So you can tailor it for each run instead of user. Having these multiples in the results is just confusing.
2. You can add an event for charge extra if residential proxy is used. See e.g. https://apify.com/vdrmota/contact-info-scraper/pricing. You can also offer it as "country selection". In ideal case, if one proxy works much better than other, you just hardcode that, e.g. we use residential for Instagram but datacenter for Google Maps.
3. This is a tricky one and we ourselves didn't yet find a great model. I think something along paying a small amount for "cached data" or making the provided data more expensive is fine.
4. The problem is simply having two subscription levels, one for Apify, other for individual Actors. This is really hard for customers to orient themselves. In a lot of cases, you can use the Apify Store Discounts where you give better price based on their Apify subscriptions. Yes, they might spend it on other Actors too but often they only use 1 or 2 Actors. We know that developers would love type of rental subscriptions but developers also benefit from a good UX of plain PPE, many have very stable income just with that
Apify
📩 Phone, Email and Contact Details Scraper · Apify
Provide a list of websites and download their emails, phone numbers, and social media details. Export results in Excel, CSV, JSON or with an API.