chore: sync Rust client with Apify OpenAPI spec v2-2026-06-30T091455Z

Version-only sync from v2-2026-06-29T142258Z. An independent operation- and
parameter-level audit of the new spec (131 paths / 231 operations), with the
apify-client-js reference as the in-scope parity authority, found no change to
the in-scope API surface. Bumps API_SPEC_VERSION and the crate version to 0.4.3
(patch) and adds two non-breaking documentation improvements.

- src/version.rs: API_SPEC_VERSION -> v2-2026-06-30T091455Z
- Cargo.toml: 0.4.2 -> 0.4.3
- CHANGELOG.md: [0.4.3]
- examples/get_account.rs: explicit chrono::Utc import (self-contained snippet)
- src/clients/run_collection.rs: runnable rustdoc example for two-arg runs().list()

Author: claude

CHANGELOG.md

@@ -4,6 +4,30 @@ All notable changes to the Rust Apify API client are documented here. The format
 based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and the project adheres
 to [Semantic Versioning](https://semver.org/).
 
+## [0.4.3] - 2026-06-30
+
+Synchronized with Apify OpenAPI specification `v2-2026-06-30T091455Z` (previously
+`v2-2026-06-29T142258Z`). An independent operation- and parameter-level audit of the new
+specification (131 paths / 231 operations) against the exposed client surface — with the
+`apify-client-js` reference client as the parity authority for which endpoints are in scope — found
+**no change to the in-scope API surface**: same paths, operations, query/header parameters, request
+bodies and response schemas. Spot-checks of the highest-churn endpoints (`POST /v2/actors/{actorId}/runs`,
+`GET /v2/store`, `GET /v2/datasets/{datasetId}/items`, `GET /v2/actor-runs` including the
+`startedAfter`/`startedBefore` filters, `POST /v2/actor-runs/{runId}/charge`,
+`POST /v2/actor-runs/{runId}/resurrect`) confirmed every documented parameter remains covered. The
+endpoints not exposed by the client (`run-sync` / `run-sync-get-dataset-items`,
+`/v2/tools/encode-and-sign` & `/v2/tools/decode-and-verify`, `/v2/browser-info`, and the keyed `POST`
+create variants that duplicate the covered `PUT` writes) remain out of scope, matching the reference
+client. No public API surface change, so this is a patch release.
+
+### Changed
+- `API_SPEC_VERSION` bumped to `v2-2026-06-30T091455Z`.
+
+### Documentation
+- `examples/get_account.rs` now imports `chrono::Utc` explicitly so the snippet is self-contained.
+- Added a runnable rustdoc example to `RunCollectionClient::list` showing the two-argument
+  `list(ListOptions, RunListOptions)` call.
+
 ## [0.4.2] - 2026-06-29
 
 Synchronized with Apify OpenAPI specification `v2-2026-06-29T142258Z` (previously

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "apify-client"
-version = "0.4.2"
+version = "0.4.3"
 authors = ["Apify Technologies <support@apify.com>"]
 description = "An official, but experimental, AI-generated and AI-maintained Rust client for the Apify API (https://apify.com)."
 license = "Apache-2.0"

examples/get_account.rs

@@ -3,6 +3,7 @@
 //! Run with: `APIFY_TOKEN=... cargo run --example get_account`
 
 use apify_client::ApifyClient;
+use chrono::Utc;
 
 #[tokio::main]
 async fn main() -> Result<(), Box<dyn std::error::Error>> {
@@ -22,7 +23,7 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> {
     // Usage for the billing cycle that contains a specific `YYYY-MM-DD` date — pass `Some(date)`
     // to look up a particular cycle, or `None` for the current one. We derive the date from the
     // current day (rather than hard-coding one) so the lookup always lands on a real cycle.
-    let date = chrono::Utc::now().format("%Y-%m-%d").to_string();
+    let date = Utc::now().format("%Y-%m-%d").to_string();
     let dated_usage = client.me().monthly_usage_for_date(Some(&date)).await?;
     if let Some(cycle) = dated_usage.get("usageCycle") {
         println!("Usage cycle containing {date}: {cycle}");

src/clients/run_collection.rs

@@ -39,6 +39,29 @@ impl RunCollectionClient {
     }
 
     /// Lists runs with offset/limit pagination and optional status/started-time filtering.
+    ///
+    /// Unlike other collections, run listing takes two arguments: the shared [`ListOptions`]
+    /// (offset/limit/desc) and a [`RunListOptions`] filter (status and start-time bounds).
+    ///
+    /// # Example
+    /// ```no_run
+    /// use apify_client::{ApifyClient, ListOptions, RunListOptions};
+    ///
+    /// # async fn run() -> Result<(), Box<dyn std::error::Error>> {
+    /// let client = ApifyClient::new("my-api-token");
+    /// let runs = client
+    ///     .runs()
+    ///     .list(
+    ///         ListOptions { limit: Some(10), desc: Some(true), ..Default::default() },
+    ///         RunListOptions { status: vec!["SUCCEEDED".to_string()], ..Default::default() },
+    ///     )
+    ///     .await?;
+    /// for run in runs.items {
+    ///     println!("{}", run.id);
+    /// }
+    /// # Ok(())
+    /// # }
+    /// ```
     pub async fn list(
         &self,
         options: ListOptions,

src/version.rs

@@ -10,4 +10,4 @@ pub const CLIENT_VERSION: &str = env!("CARGO_PKG_VERSION");
 /// and verified against.
 ///
 /// This corresponds to the `info.version` field of the Apify OpenAPI document.
-pub const API_SPEC_VERSION: &str = "v2-2026-06-29T142258Z";
+pub const API_SPEC_VERSION: &str = "v2-2026-06-30T091455Z";