diff --git a/docs/02_concepts/01_actor_lifecycle.mdx b/docs/02_concepts/01_actor_lifecycle.mdx index d6bb90ad..773405df 100644 --- a/docs/02_concepts/01_actor_lifecycle.mdx +++ b/docs/02_concepts/01_actor_lifecycle.mdx @@ -103,7 +103,3 @@ Before triggering a reboot, persist any essential state externally (e.g., to the Update the status only when the user's understanding of progress changes - avoid frequent updates for every processed item. Detailed information should go to logs or storages (dataset, key-value store) instead. {StatusMessageExample} - -## Conclusion - -This page has presented the full Actor lifecycle: initialization, execution, error handling, rebooting, shutdown and status messages. You've seen how the SDK supports both context-based and manual control patterns. For deeper dives, explore the `Actor` API reference, [guides](../guides/beautifulsoup-httpx), and [platform documentation](https://docs.apify.com/platform). diff --git a/docs/02_concepts/02_actor_input.mdx b/docs/02_concepts/02_actor_input.mdx index a5ef20f8..16c31a5e 100644 --- a/docs/02_concepts/02_actor_input.mdx +++ b/docs/02_concepts/02_actor_input.mdx @@ -37,9 +37,3 @@ Actors commonly receive a list of URLs to process via their input. The `Actor.get_input`, encrypted fields are automatically decrypted using the Actor's private key, which is provided by the platform via environment variables. You receive the plaintext values directly. - -## Conclusion - -This page has shown how to read Actor input with `Actor.get_input`, how to load URL sources with `ApifyRequestList`, and how secret input fields are decrypted automatically when you read them. - -For more details on Actor input and how to define input schemas, see the [Actor input](https://docs.apify.com/platform/actors/running/input) and [input schema](https://docs.apify.com/platform/actors/development/input-schema) documentation on the Apify platform. diff --git a/docs/02_concepts/03_storages.mdx b/docs/02_concepts/03_storages.mdx index f44a98c4..054ab7ae 100644 --- a/docs/02_concepts/03_storages.mdx +++ b/docs/02_concepts/03_storages.mdx @@ -17,7 +17,10 @@ import KvsIteratingExample from '!!raw-loader!roa-loader!./code/03_kvs_iterating import KvsPublicRecordExample from '!!raw-loader!roa-loader!./code/03_kvs_public_url.py'; import RqExample from '!!raw-loader!roa-loader!./code/03_rq.py'; -The `Actor` class provides methods to work either with the default storages of the Actor, or with any other storage, named or unnamed. +The `Actor` class provides methods to work either with the default storages of the Actor, or with any other storage, named or unnamed. + +For details on storage types, see [Storage](https://docs.apify.com/platform/storage). + ## Types of storages @@ -186,9 +189,3 @@ To check if all the requests in the queue are handled, you can use the {UseStateExample} - -## Conclusion - -This page has described the events emitted during a run (`SYSTEM_INFO`, `MIGRATING`, `ABORTING`, `PERSIST_STATE`, and `EXIT`): how to handle them with `Actor.on`, and how to persist state automatically with `Actor.use_state`. - -For more details on platform events and state persistence, see the [system events](https://docs.apify.com/platform/actors/development/programming-interface/system-events) and [state persistence](https://docs.apify.com/platform/actors/development/state-persistence) documentation on the Apify platform. diff --git a/docs/02_concepts/05_proxy_management.mdx b/docs/02_concepts/05_proxy_management.mdx index 2a29bb51..d3c37fd4 100644 --- a/docs/02_concepts/05_proxy_management.mdx +++ b/docs/02_concepts/05_proxy_management.mdx @@ -121,9 +121,3 @@ Make sure you have the `httpx` library installed: ```bash pip install httpx ``` - -## Conclusion - -This page has explained how to manage proxies with the `ProxyConfiguration` class: using Apify Proxy or your own servers, keeping sessions sticky across requests, configuring tiered proxy rotation, and feeding proxy settings from Actor input. - -For full details on proxy configuration options, see the `ProxyConfiguration` API reference and the [Apify Proxy documentation](https://docs.apify.com/proxy). diff --git a/docs/02_concepts/06_interacting_with_other_actors.mdx b/docs/02_concepts/06_interacting_with_other_actors.mdx index f7b3fd33..1a362d7a 100644 --- a/docs/02_concepts/06_interacting_with_other_actors.mdx +++ b/docs/02_concepts/06_interacting_with_other_actors.mdx @@ -15,6 +15,9 @@ import ApiLink from '@theme/ApiLink'; The Apify SDK lets you start, call, and transform (metamorph) other Actors directly from your Actor code. This is useful for composing complex workflows from smaller, reusable Actors. +For the full list of methods for interacting with other Actors, see the `Actor` class in the API reference. For details on running Actors and Actor tasks on the platform, see [Actors](https://docs.apify.com/platform/actors) and [Actor tasks](https://docs.apify.com/platform/actors/tasks). + + ## Actor start The `Actor.start` method starts another Actor on the Apify platform, and immediately returns the details of the started Actor run. @@ -62,9 +65,3 @@ When you set `gracefully=True`, the platform sends `ABORTING` and `PERSIST_STATE {InteractingAbortExample} - -## Conclusion - -This page has shown how to interact with other Actors from your code: starting a run with `Actor.start`, waiting for it to finish with `Actor.call` or `Actor.call_task`, transforming a run with `Actor.metamorph`, and stopping one with `Actor.abort`. - -For the full list of methods for interacting with other Actors, see the `Actor` API reference. For more details on running Actors and Actor tasks on the platform, see the [Actors](https://docs.apify.com/platform/actors) and [Actor tasks](https://docs.apify.com/platform/actors/tasks) documentation. diff --git a/docs/02_concepts/07_webhooks.mdx b/docs/02_concepts/07_webhooks.mdx index a02dd6a5..a5a851d8 100644 --- a/docs/02_concepts/07_webhooks.mdx +++ b/docs/02_concepts/07_webhooks.mdx @@ -10,9 +10,7 @@ import ApiLink from '@theme/ApiLink'; import WebhookExample from '!!raw-loader!roa-loader!./code/07_webhook.py'; import WebhookPreventingExample from '!!raw-loader!roa-loader!./code/07_webhook_preventing.py'; -Webhooks allow you to configure the Apify platform to perform an action when a certain event occurs. For example, you can use them to start another Actor when the current run finishes or fails. - -You can learn more in the [documentation for webhooks](https://docs.apify.com/platform/integrations/webhooks). +[Webhooks](https://docs.apify.com/platform/integrations/webhooks) allow you to configure the Apify platform to perform an action when a certain event occurs. For example, you can use them to start another Actor when the current run finishes or fails. ## Creating an ad-hoc webhook dynamically @@ -31,9 +29,3 @@ To ensure that duplicate ad-hoc webhooks won't get created in a case of Actor re {WebhookPreventingExample} - -## Conclusion - -This page has shown how to create ad-hoc webhooks dynamically with `Actor.add_webhook` and how to avoid creating duplicates across Actor restarts using the `idempotency_key` parameter. - -For more information about webhooks, including event types and payloads, see the [Apify webhooks documentation](https://docs.apify.com/platform/integrations/webhooks). diff --git a/docs/02_concepts/08_access_apify_api.mdx b/docs/02_concepts/08_access_apify_api.mdx index 4fee2c6a..774002bc 100644 --- a/docs/02_concepts/08_access_apify_api.mdx +++ b/docs/02_concepts/08_access_apify_api.mdx @@ -35,9 +35,3 @@ To create a completely new instance of the client (for example, to use a differe This is useful when the Actor's own token is not the right one, for instance when acting on behalf of another user, or when you want different retry and timeout behavior than the shared `Actor.apify_client` instance. - -## Conclusion - -This page has shown how to reach the Apify API directly for platform features the SDK does not wrap. You can use the built-in client exposed by `Actor.apify_client`, or a freshly configured one created with `Actor.new_client`. - -For the full API client documentation, see the [Apify API Client for Python](https://docs.apify.com/api/client/python). diff --git a/docs/02_concepts/09_logging.mdx b/docs/02_concepts/09_logging.mdx index a953a3b0..80712da2 100644 --- a/docs/02_concepts/09_logging.mdx +++ b/docs/02_concepts/09_logging.mdx @@ -113,7 +113,3 @@ You can further decide whether you want to redirect just new logs of the ongoing {RedirectLogExistingRun} - -## Conclusion - -This page has covered how the SDK logs through the `apify` logger: setting the log level, formatting output with `ActorLogFormatter`, using the logger at each level, and redirecting logs from other Actor runs back into the parent run. For more on the underlying logging machinery, see Python's standard [`logging`](https://docs.python.org/3/library/logging.html) module documentation. diff --git a/docs/02_concepts/10_configuration.mdx b/docs/02_concepts/10_configuration.mdx index 96ec8a7a..da1009ca 100644 --- a/docs/02_concepts/10_configuration.mdx +++ b/docs/02_concepts/10_configuration.mdx @@ -13,7 +13,7 @@ import ApiLink from '@theme/ApiLink'; The `Actor` class is configured through the `Configuration` class, which reads its settings from environment variables. When running on the Apify platform or through the Apify CLI, configuration is automatic — manual setup is only needed for custom requirements. -If you need some special configuration, you can adjust it either through the `Configuration` class directly, or by setting environment variables when running the Actor locally. +If you need some special configuration, you can adjust it either through the `Configuration` class directly, or by setting [environment variables](https://docs.apify.com/platform/actors/development/programming-interface/environment-variables) when running the Actor locally. To see the full list of configuration options, check the `Configuration` class or the list of environment variables that the Actor understands. @@ -65,9 +65,3 @@ The `Actor.is_at_home` method ret {PlatformDetectionExample} - -## Conclusion - -This page has shown how to configure an Actor through the `Configuration` class or environment variables, which options you are most likely to set yourself, and how to inspect the runtime environment with `Actor.get_env` and `Actor.is_at_home`. - -For the full list of configuration options, see the `Configuration` API reference. For a complete list of environment variables available on the platform, see the [environment variables](https://docs.apify.com/platform/actors/development/programming-interface/environment-variables) documentation. diff --git a/docs/02_concepts/12_storage_clients.mdx b/docs/02_concepts/12_storage_clients.mdx index 7b953fd9..991e6eb1 100644 --- a/docs/02_concepts/12_storage_clients.mdx +++ b/docs/02_concepts/12_storage_clients.mdx @@ -12,6 +12,8 @@ import CustomStorageClientExample from '!!raw-loader!roa-loader!./code/12_custom Storage clients are the components that read and write your [storages](./storages): datasets, key-value stores, and request queues. The Apify SDK selects an appropriate client automatically based on where the Actor runs. For most Actors you never need to think about them. This page explains the available clients and how to customize them when you do. +For details on how storage clients work and how to write your own, see the [Crawlee storage clients guide](https://crawlee.dev/python/docs/guides/storage-clients). + ## How the Actor selects a storage client By default, the Actor uses a `SmartApifyStorageClient`, a hybrid client that delegates to one of two underlying clients depending on the environment: @@ -69,9 +71,3 @@ You can replace either of the underlying clients, for example to keep all local The Actor's storage client must be a `SmartApifyStorageClient`. Setting a bare `ApifyStorageClient` or `MemoryStorageClient` directly in the service locator raises an error. Wrap it in a `SmartApifyStorageClient` as shown above. ::: - -## Conclusion - -This page has explained how the Actor selects a storage client, the clients available in the `apify.storage_clients` module, the difference between the single and shared request-queue clients, and how to customize the client through the service locator. - -For a deeper look at how storage clients work and how to write your own, see the [Crawlee storage clients guide](https://crawlee.dev/python/docs/guides/storage-clients). diff --git a/docs/02_concepts/13_exceptions.mdx b/docs/02_concepts/13_exceptions.mdx index a5a7e7d0..8d7bec3f 100644 --- a/docs/02_concepts/13_exceptions.mdx +++ b/docs/02_concepts/13_exceptions.mdx @@ -62,7 +62,3 @@ To detect the limit, check the `event_charge_limit_reached` field on the `Charge ## Errors while crawling If your Actor runs a [Crawlee](https://crawlee.dev/python) crawler, failures inside request handlers surface as Crawlee exceptions. Crawlee handles the retries and session rotation around them, so a single failing request doesn't stop the crawl. API calls you make from inside a handler still raise `ApifyApiError`. For how to handle those errors, see [Errors from the Apify API](#errors-from-the-apify-api). - -## Conclusion - -Most failures you handle at runtime are `ApifyApiError` from the API client. Catch it to cover any API failure, and reach for a subclass or the HTTP `status_code` when you need finer control. The standard [`RuntimeError`](https://docs.python.org/3/library/exceptions.html#RuntimeError), [`ValueError`](https://docs.python.org/3/library/exceptions.html#ValueError), and [`TypeError`](https://docs.python.org/3/library/exceptions.html#TypeError) signal a bug or bad input, so correct the call rather than catch them. After `Actor.call`, check `run.status` to react to a failed run, and let Crawlee handle the errors raised inside a crawler.