[vdusek]

Adds ActorClient.server() and ActorClientAsync.server(), which return an ActorServerClient / ActorServerClientAsync for Server Actors (formerly Actor Standby):

actor_server_client = client.actor('username/actor-name').server()
response = actor_server_client.request('/search', params={'q': 'apify'})
url = actor_server_client.get_url()
spec = actor_server_client.get_openapi_spec()

• request() sends a request to the Actor's server. The host always comes from the Actor's standbyUrl. The token goes in the X-Apify-Authorization header, which the platform strips, so headers the caller passes, Authorization included, reach the Actor as they are.
• request() returns the server's response whatever its status. Only 429 and 503 are retried, since other statuses may come from the Actor's code. Network errors and timeouts aren't retried, since the Actor may have already handled the request. It raises only when it gets no response: the Actor doesn't exist or isn't a Server Actor, or the request fails or times out.
• request() sends bodies uncompressed unless compression is set, returns the body unread with stream=True, and defaults to the long timeout to cover a cold start.
• get_url() returns the server URL. It's fetched once per ActorClient, by get_url() or get_openapi_spec().
• get_openapi_spec() returns the web server schema from the build that serves the server (actorStandby.build, or latest), or None if there's none. The schema field comes from fix(openapi): add missing fields to the Actor definition schema apify-docs#3115.
• get_url() and get_openapi_spec() take a timeout.

ActorClient.standby() is a deprecated alias of server() and will be removed in v4.

Other changes:

• HttpClient.call and HttpClientAsync.call take new arguments: compression, authorization_header, raise_for_status, retry_status_codes, and retry_transport_errors. A custom HTTP client that overrides call must accept and honor them.
• The docstring sync script no longer turns ApifyClientError into a nonexistent ApifyClientAsyncError.
• A Server Actors concepts page, unit tests, and an integration test against a temporary echo Server Actor.

Closes: #973

✍️ Drafted by Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 97.85714% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.70%. Comparing base (4bfd88a) to head (0581db0).
⚠️ Report is 3 commits behind head on master.

Files with missing lines	Patch %	Lines
src/apify_client/_resource_clients/actor_server.py	96.73%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1153      +/-   ##
==========================================
+ Coverage   95.66%   95.70%   +0.04%     
==========================================
  Files          61       62       +1     
  Lines        6459     6593     +134     
==========================================
+ Hits         6179     6310     +131     
- Misses        280      283       +3     

Flag	Coverage Δ
integration	90.96% <80.00%> (-0.27%)	⬇️
unit	90.62% <97.85%> (+0.27%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Pijukatel]

Looks good to me.

Just an idea for consideration since this will be a new public way to work with server actors, we can carefully consider the options.

What if ServerActor would be a component of Actor? It would work a little bit around the name you are not sure about. Server Actor is clearly something different than normal Actor. Maybe we can make the distinction less blurry?
The methods and functionality related to the server would be nicely grouped together, not inflating the normal Actor.

So instead of
ActorClient.get_server_url
ActorClient.server_request
ActorClient.get_server_openapi_spec

You would get something like
ActorClient.server.get_url
ActorClient.server.request
ActorClient.server.get_openapi_spec

[vdusek]

@Pijukatel Thanks, good idea, I've implemented it. The methods now live on a new ActorServerClient, which you get from ActorClient.server() (so actor.server().request(...), .get_url(), .get_openapi_spec()). I kept a deprecated Standby alias, ActorClient.standby(), which returns the same client, and I updated the docs page. Could you give it a final check?

Also tagging @janbuchar, since one more pair of eyes on the design of this new feature would be great.

[Pijukatel]

@Pijukatel Thanks, good idea, I've implemented it. The methods now live on a new ActorServerClient, which you get from ActorClient.server() (so actor.server().request(...), .get_url(), .get_openapi_spec()). I kept a deprecated Standby alias, ActorClient.standby(), which returns the same client, and I updated the docs page. Could you give it a final check?

Also tagging @janbuchar, since one more pair of eyes on the design of this new feature would be great.

I like this implementation. It is well separated and even though the distinction is quite blurry on the platform, here it feels well separated.