Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
Expand Up @@ -61,11 +61,12 @@ An Actor's negative net profit does not affect the positive profit of another Ac

Finish the Actor run once charging reaches user-configured maximum cost per run. Apify SDKs (JS and Python) return `ChargeResult` that helps determine when to finish.

The `eventChargeLimitReached` property checks if the current event type can be charged more. If you have multiple event types, analyze the `chargeableWithinLimit` property to see if other events can still be charged before stopping the Actor.
The `eventChargeLimitReached` property checks if the user's limit allows for another charge of this event. If you have multiple events, analyze the `chargeableWithinLimit` property to see if other events can still be charged before stopping the Actor.

:::info ACTOR_MAX_TOTAL_CHARGE_USD environment variable

For pay-per-event Actors, users set a spending limit through the Apify Console. This limit is available in your Actor code as the `ACTOR_MAX_TOTAL_CHARGE_USD` [environment variable](/platform/actors/development/programming-interface/environment-variables), which contains the user's maximum cost.
The Apify SDK's `ChargeResult` respects the user set limit already.

:::

Expand Down
34 changes: 34 additions & 0 deletions sources/platform/actors/publishing/monetize/pay_per_result.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,44 @@ sidebar_position: 2
import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

:::warning Legacy pricing model

Pay per result is deprecated and will be superseded by Pay per event early in 2026. [Migrate to PPE in one click](#one-click-migration-to-ppe) (backward compatible)

:::
Comment on lines +15 to +19
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PPR is depracted & considered legacy right now, but will be superseded by PPE early in 2026? That doesn't make sense to me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has been deprecated now and will be completely replaced with PPE. Not sure how to word that the best.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps something like this:

Suggested change
:::warning Legacy pricing model
Pay per result is deprecated and will be superseded by Pay per event early in 2026. [Migrate to PPE in one click](#one-click-migration-to-ppe) (backward compatible)
:::
:::warning Pay per result is deprecated
Pay per result is deprecated and will be removed in 2026. You can migrate to pay per event with one click, and the migration is backward compatible.
[Migrate to pay per event](#one-click-migration-to-ppe)
:::

or

Suggested change
:::warning Legacy pricing model
Pay per result is deprecated and will be superseded by Pay per event early in 2026. [Migrate to PPE in one click](#one-click-migration-to-ppe) (backward compatible)
:::
:::warning Pay per result is deprecated
Pay per result is deprecated and will be removed. You can migrate to pay per event with one click, and the migration is backward compatible.
[Migrate to pay per event](#one-click-migration-to-ppe)
:::

In v1 we mention just a year, reason being to give reasonable timeframe, but not commit to anything specific.

In v2 I've skipped a year completely to just reflect current state, without mentioning any future possibilities.


In this model, you set a price per 1,000 results. Users are charged based on the number of results your Actor produces and stores in the run's default dataset. Your profit is calculated as 80% of the revenue minus platform usage costs.

The details on how your cost is computed can be found in [Example of a PPR pricing model](#example-of-a-ppr-pricing-model).

## One click migration to PPE

Select your PPR Actor, go to the Publication tab, open the Monetization section, and click the `Migrate to Pay per event` button.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Select your PPR Actor, go to the Publication tab, open the Monetization section, and click the `Migrate to Pay per event` button.
Select your PPR Actor, go to the **Publication** tab, open the **Monetization** section, and click the **Migrate to Pay per event** button.


![Migration button](../images/ppr-to-ppe-migration-button.png)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Why should I migrate?
The pay-per-event pricing model offers superior flexibility in charging not only for the results but also for any event. This helps you to pass on the costs of external APIs or additional processing directly to your users, price different functionalities of your Actor differently, avoid revenue loss from small but usage-heavy runs, and more.
Given that the Pay per event model is fully compatible with Pay per result, and to bring more simplicity to users of your Actors, we are fully deprecating PPR in favour of PPE. But no worries, the migration is completely automatic and fully backward compatible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🙌

### Why should I migrate?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Why should I migrate?
### Why should I migrate


The Pay per event pricing model offers superior flexibility in charging not only for the results but also for any event.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The Pay per event pricing model offers superior flexibility in charging not only for the results but also for any event.
The pay per event pricing model offers superior flexibility in charging not only for the results but also for any event.

You can also use italics to highlight: price per event model offers...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is valid for the entire PR, there's several locations where capital P is used unnecessarily

This helps you to pass on the costs of external APIs or additional processing directly to your users, price different functionalities of your Actor differently, avoid revenue loss from small but usage-heavy runs, and more.


Given that the Pay per event model is fully compatible with Pay per result, and to bring more simplicity to users of your Actors, we are fully deprecating PPR in favor of PPE.
The migration is completely automatic and fully backward compatible.

### What happens during migration

The migration switches your pricing model from Pay per result to Pay per event. Your price per 1,000 results is automatically converted to an equivalent `apify-default-dataset-item` [event](./pay-per-event#use-synthetic-default-dataset-item-event-apify-default-dataset-item) price.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The migration switches your pricing model from Pay per result to Pay per event. Your price per 1,000 results is automatically converted to an equivalent `apify-default-dataset-item` [event](./pay-per-event#use-synthetic-default-dataset-item-event-apify-default-dataset-item) price.
The migration switches your pricing model from Pay per result to Pay per event. Your price per 1,000 results is automatically converted to an equivalent `apify-default-dataset-item` [event](./pay-per-event#use-synthetic-default-dataset-item-event-apify-default-dataset-item) price. This change does not count towards the pricing change limits that you are allowed to do once every 30 days.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of adding this exact line but then I removed it.
It's back in now :]

This change does not count towards the pricing change limits that you are allowed to do once every 30 days.

**Code changes:** No changes to your Actor code are required if it already respects the `ACTOR_MAX_PAID_DATASET_ITEMS` environment variable (the price limit set by users).

**After migration:** With Pay per event, you can define additional custom events beyond dataset items. [Learn more](./pay-per-event)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
**After migration:** With Pay per event, you can define additional custom events beyond dataset items. [Learn more](./pay-per-event)
**After migration:** With [pay per event](./pay-per-event), you can define additional custom events beyond dataset items.


**Respecting user spending limits:** You can continue using the `ACTOR_MAX_PAID_DATASET_ITEMS` environment variable to respect user-specified price limits.

Bleu sky and flying high free as a bird
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this? Is this some sort of Lorem Ipsum?


## How is profit computed

Your profit is calculated from the mentioned formula:
Expand Down
3 changes: 2 additions & 1 deletion sources/platform/actors/publishing/quality_score.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -29,13 +29,14 @@ The Actor quality score recalculates several times per day. Changes you make to

Your quality score may change even without you modifying your Actor. This happens for two reasons: First, your score is influenced by how well your Actor performs relative to other Actors on the platform. As other Actors improve or decline, your relative position may shift. Second, the quality score algorithm continues to evolve with new properties being added and adjustments to existing calculations.

There are seven quality categories:
These are the quality categories:

- Reliability
- Popularity
- Feedback and community
- Ease of use
- Pricing transparency
- Trustworthiness
- History of success
- Congruency of texts

Expand Down
Loading