--- title: Server Actors url: https://docs.apify.com/actors/running/server-actors.md parents: - [Apify documentation](https://docs.apify.com/llms.txt) - [Actors](https://docs.apify.com/actors.md) - [Run](https://docs.apify.com/actors/running.md) previous: [Tasks](https://docs.apify.com/actors/running/tasks.md) next: [Schedules](https://docs.apify.com/actors/running/schedules.md) --- > ## Documentation index > Fetch the complete documentation index at: https://docs.apify.com/llms.txt > Use this file to discover all available pages before exploring further. # Server Actors There are two ways to use an Actor. Through the input interface, you give it an input and start a run, which suits batch jobs such as a large data extraction. Through the server interface, you send an HTTP request to the Actor's URL and get the response straight back, without waiting for a run to start. Server Actors (formerly Actor Standby mode) are Actors with the server interface enabled. They stay ready in the background and respond to requests in real time, like any web API. A Server Actor is either multi-tenant or single-tenant. A multi-tenant Server Actor runs in the developer's account and serves all its users, while a single-tenant Server Actor starts a separate run in your account. Most of this page applies to both. Multi-tenant and single-tenant Server Actors describes what the tenancy changes for you. To build your own Server Actor, see [Develop Server Actors](https://docs.apify.com/actors/development/programming-interface/server-actors.md). ## Check if an Actor is a Server Actor If an Actor has the server interface enabled, its detail page shows the **Server** tab. The tab contains the hostname of the Actor's server, and the Actor README describes the endpoints, the parameters they accept, and what they return. If the Actor defines a [web server schema](https://docs.apify.com/actors/development/actor-definition/web-server-schema.md), the tab also shows an interactive list of its endpoints, where you can send requests directly from the browser. You don't need to start the Actor. Send a request to that hostname and endpoint, and you get the results. ## Get the server interface URL The server interface URL typically combines the Actor owner's username and the Actor name, for example: ```text https://jane-doe--my-actor.apify.actor ``` The Actor also responds on a URL built from its ID, which keeps working if the Actor or its owner is renamed: ```text https://92c4oi4fpzy7rprlf.apify.actor ``` The server interface URL always stays the same, so you can share it publicly or hardcode it in applications that call the Actor. Copy the URL from the **Server** tab instead of building it from the username and Actor name, because some Actors use a different hostname format, like `rag-web-browser.apify.actor`. ## Send requests to the Actor If you use an Actor built by someone else, its README describes how to pass the input. Server Actors behave as standard HTTP servers. Use any [HTTP request method](https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods), such as GET, POST, PUT, or DELETE, and pass the input in the [query string](https://en.wikipedia.org/wiki/Query_string) or the [request body](https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages#body). ## Authenticate requests Authenticate requests to Server Actors the same way as [requests to the Apify API](https://docs.apify.com/integrations/api.md). Provide your [API token](https://docs.apify.com/integrations/api.md#api-token) in one of two ways: * *(Recommended)* Include the token in the `Authorization` header as `Bearer `. This keeps the token out of server logs. ```bash curl -H "Authorization: Bearer my_apify_token" \ https://rag-web-browser.apify.actor/search?query=apify ``` * Append the token to the request URL as the `token` query parameter. It's less secure, so use this option only when you can't modify the request headers. ```text https://rag-web-browser.apify.actor/search?query=apify&token=my_apify_token ``` The platform removes the token from the request before forwarding it, so the token doesn't reach the Actor's code. If the Actor reads the `Authorization` header for its own authentication, send your Apify token in the `X-Apify-Authorization` header instead. Scoped tokens work for requests to Server Actors. To let a third-party service call your Actor without access to your entire account, give it a [scoped token](https://docs.apify.com/integrations/api.md#limited-permissions) with only the permissions it needs. Restricted access is not supported A scoped token also has a [restricted access](https://docs.apify.com/integrations/api.md#restricted-access-restrict-what-actors-can-access-using-the-scope-of-this-actor) option that limits what the Actor's run can access. Server Actors don't support that option. ## Multi-tenant and single-tenant Server Actors The Actor's developer sets its tenancy. The Actor's detail page shows it in the **Features** section, as **Multi-tenant** or **Single-tenant**. Tenancy decides whose account runs the Actor, what you pay for, and whether you can change the server configuration. ### Multi-tenant Server Actors A multi-tenant Server Actor works like any other API on the internet. Its developer manages it, and you send requests to it. It runs in the developer's account and serves all its users from shared runs. You pay only for the events the Actor charges, not for the platform usage of its runs. No runs appear in your **Runs** tab, and the Actor appears in your recently used Actors instead. The developer sets the server configuration, and you can't override it with a task. The Actor receives only your Apify user ID, not your name, email, or API token. It can't start runs or read storages in your account. ### Single-tenant Server Actors A single-tenant Server Actor works like a server that you install and configure yourself. It starts its runs in your account, and only you use them. You pay for the platform usage of those runs, plus the event charges if the Actor uses the [pay-per-event pricing model](https://docs.apify.com/actors/monetize/pay-per-event.md). The developer sets the default server configuration. Unless the developer locked it, you can override it with a task. ## Run the Actor through its input interface If the Actor has an input schema, you can also start a run through its input interface. Modify the input in the **Input** tab and select **Start**. If the Actor has no input schema, Apify Console disables the **Input** tab. Not every Server Actor supports the input interface. If it doesn't, the run might fail, return empty results, or start its server. Check the Actor README for what the Actor supports. Tasks of a multi-tenant Server Actor don't serve requests to the server interface. A task that runs the Actor through its input interface keeps working. ## Limits and scaling The platform scales Server Actor runs automatically and applies timeouts and rate limits to the incoming requests. ### Automatic scaling For a multi-tenant Server Actor, the developer manages scaling, and you only send requests. For a single-tenant Server Actor, the platform starts runs in your account to match the incoming requests. They appear in the Actor **Runs** tab with the origin shown as **Server**. These runs aren't shared with other users, even when you use the Actor-level hostname with the default configuration. The platform checks a run's readiness once, before the run starts serving requests, and performs no health checks after that. ### Request timeouts A request to a Server Actor must receive its first response within 5 minutes. This is the overall timeout for the request. If the platform finds no run to handle the request within 2 minutes, for example because a new run has to start first, the request fails with a `429` error. ### Rate limits The platform rate-limits incoming requests to Server Actors per user account. The limit is the same on all standard subscription plans, and custom plans can raise it. Responses include the current limit in the `X-RateLimit-Limit` header. When you exceed the limit, the platform responds with a [429 Too Many Requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429) error. ### Usage limit If your account goes over its monthly usage hard limit, the platform rejects your new requests to Server Actors. A request that is already in progress isn't stopped. ## Billing What you pay for depends on the tenancy, as described in Multi-tenant and single-tenant Server Actors. For a single-tenant Server Actor, the platform bills your runs like any other runs in your account. A run also consumes resources while it waits for requests, until the idle timeout stops it, so expect usage even when no requests arrive. ## Use Server Actors as MCP servers If the Actor exposes a [Model Context Protocol (MCP)](https://docs.apify.com/mcp.md) server, its MCP endpoint is the server interface URL followed by the path defined in the Actor's [webServerMcpPath](https://docs.apify.com/actors/development/actor-definition/actor-json.md) property. Apify Console shows the MCP URL in the Actor's **Server** tab. Authenticate requests to the MCP endpoint the same way as any other request to a Server Actor. ## Override the configuration with a task You can override the server configuration only for a single-tenant Server Actor, and only if its developer didn't lock it. If you use an Actor built by someone else, the Actor-level hostname always uses the developer's default [server configuration](https://docs.apify.com/actors/development/programming-interface/server-actors.md#configure-the-server). To override it: 1. In [Apify Console](https://console.apify.com), open the Actor and select **Save as a new task**. 2. Open the task's **Settings** tab. 3. Modify the configuration. 4. In your application, use the task's hostname instead of the Actor's.