Per-Request Proxy Pricing

What you pay for

You pay for the number of requests counted by the provider. It may sell fixed packages or charge as you use the service. Prices are often quoted per thousand or per million requests. That makes tariffs easier to compare, but it does not tell you how much you must spend at checkout: the smallest package may contain more requests.

The same word, “request,” can describe different services. An ordinary proxy forwards your application's requests to websites and returns their responses. Your application loads the pages and extracts the data. With a data collection API, the price may also include running a browser, handling access restrictions, and preparing the results. Comparing the request price alone is therefore not enough; you need to know what the service does for that price.

This pricing is convenient for work that follows a schedule. You may already know how many pages to check and how often. Next, find out how many requests each check uses. You can then estimate the package needed for a month and how much usage will grow if you add more pages.

Response size does not necessarily affect the price. If the tariff charges the same amount for each request, retrieving more data in one response may cost as much as retrieving a small response. Check what the tariff includes, though: there may be limits on bandwidth, response size, or execution time. Additional data processing may also have a separate charge.

A request package does not determine how many IP addresses you receive. A rotating service, for example, can provide access to an IP pool through a shared connection endpoint. IP changes and keeping an address for a session depend on the service settings. An IP change alone does not tell you how many requests will be charged.

What the service counts as one request

Start by separating a request from a connection. An HTTP request asks a website to do something, such as return a page or supply data. The website sends a response. Data travelling in both directions does not, by itself, mean that two requests should be deducted. That would require a separate billing rule.

A connection is the channel through which the application communicates with the server. Several requests can use the same connection. HTTP/1.1 allows a connection to be reused, while HTTP/2 allows several exchanges to run over it at once. Request count, connections opened, and connections active at the same time are therefore different measurements.

HTTPS adds another detail. When connecting through an HTTP proxy, the application commonly sends a CONNECT command to create a tunnel to the website. Later requests travel inside that tunnel in encrypted form. The proxy forwards the data but, in ordinary use, cannot read the individual HTTP requests. A SOCKS proxy also provides a connection to the destination; each application action does not necessarily need a new connection.

For this reason, some services use “request” to mean a connection or another event their proxy server can count. Others count individual HTTP requests or calls to an API. The request count in a browser's developer tools may therefore differ from usage in the provider's dashboard. Support for HTTP, HTTPS, or SOCKS5 alone does not establish the counting rule.

Before buying a large package, run a small test. Record how many tasks the application completes and how many requests the service deducts. Use the same application, protocol, and settings you intend to use later. A test with a simple HTTP client will not show the usage of a browser that also loads scripts and other page resources.

Why one page can use several requests

Opening a page often requires more than its main document. The browser separately loads styles, scripts, images, and data. An open page may continue contacting the server for updates. Some of these requests also pass through the proxy, depending on the application settings. How they are charged depends on the tariff.

Following a redirect adds a request. If the website responds that a page is at another address, an application configured to follow the redirect sends another HTTP request to that address. Fetching one document with a simple client and opening the complete page in a browser may therefore use different numbers of requests. The number of URLs in your list does not yet tell you how many requests processing them will take.

An API can work the other way: one request may retrieve many records. In this example, a browser makes five requests to load a headphone product page with its price. An application uses the same proxy to call that retailer’s catalogue API and retrieves five product prices in one request. This is the retailer’s API, which supplies product data. If it returns the catalogue in pages, each page needs another request. Sometimes you can increase the products per response, provided the API supports this setting and returns all the data you need.

This approach helps you get more useful work from a package. Repeatedly loading complete pages, fetching data you already saved, and checking prices more often than necessary can quickly use up the allowance. Retrieving several products per call, saving results, and choosing a suitable checking frequency reduces the requests needed for the same job. At the same workload, the allowance can last longer within the package’s validity period; alternatively, you can use it to check more products.

It helps to measure usage per completed task. That might mean checking one page, retrieving a complete list, or checking an element that appears after scripts run. Measure the whole sequence needed to reach that result. This includes extra page loads that are easy to miss when counting only the starting URLs.

Where this pricing model is useful

Scheduled monitoring

Request usage can be tied to regular checks. An application might monitor page availability, changes in public listings, or search results for a required region. You know the number of targets and checking frequency in advance. A test shows how many requests each check uses and helps estimate monthly consumption.

Different pages do not have to be checked equally often. If information changes once a day, checking every minute will usually return the same data. More frequent checks can be reserved for pages where detecting a change quickly matters. This keeps the package available for observations you need.

Collecting data through APIs and directories

Usage here depends on how the website supplies its information. If the list already contains everything you need, there is no reason to open each detail page. Extra requests can be reserved for items with missing data or records that have changed since the previous run. The more required data you retrieve in one call, the fewer requests the complete collection needs.

You also need to account for what the service does. A search API may return parsed results, while an ordinary proxy leaves downloading and processing to your application. These are different amounts of work. When comparing prices, check what the response contains and what you still need to do yourself.

Site audits and browser checks

A technical audit often has a clear sequence: open an address, check the response, follow a redirect if needed, and save the finding. If most addresses are handled similarly, a test makes usage easier to estimate. A browser check may need more requests because it depends on scripts, images, and working page elements.

Choose the checking method for its purpose. A simple client is often enough to see whether a page responds. Testing a checkout form requires loading what the form needs to work. Disabling required files will reduce requests, but the test will no longer show what the user experiences.

How errors and retries affect usage

A sent request does not always return the data you need. A website may return an error, an access challenge, or a different page. Even HTTP 200 does not guarantee that the application received what it wanted: the status reports success at HTTP level, while the response content needs a separate check.

Billing rules for these requests vary. Some services count sent requests. Others charge only for responses that meet their definition of successful completion. A managed API may include several internal attempts to retrieve data in the price of one response. Additional modes or features sometimes change the billing rules. “Pay per request” therefore does not automatically mean “pay only for retrieved data.”

A retry by your application is different from a retry inside the service. When the application sends the request again, it creates a new request. When the service retries work you already submitted, those attempts may be included in its price. Find out which attempts are deducted from your package.

During a test, record three numbers: tasks started, requests charged, and tasks completed. Completion depends on the purpose. For data collection, the response must contain the required fields and sufficiently recent information. For availability monitoring, correctly detecting an unavailable website is also a completed check.

These numbers help show what the work really costs. Cheap requests may be poor value if responses constantly need another attempt or must be discarded. A more expensive service may do some of the work for you. Compare the spending needed to get the required result, including the work left to your application.

How to calculate the package you need

First, count the planned work: how many targets need processing and how often. Then add requests needed beyond the normal fetch, such as retries observed during testing. Calculate different groups of pages separately if they behave differently. Keep a reserve for workload growth separate too, so that the same extra requests are not added twice.

Take an illustrative example. An application checks 150 URLs every 30 minutes for 30 days. Assume that a normal check uses one request under the selected tariff, and additional attempts increase usage by 5%. All figures and prices in this example are hypothetical; they are not provider test results or a ProxyCompass tariff.

The selected package leaves a reserve of 23,200 requests. It can cover workload growth while the package remains valid. Expected retries are already included in the 10,800 additional attempts; this reserve should not be counted again as usage for those same retries.

Suppose the package costs $10. It contains 250 thousand requests, so the nominal price per thousand is $0.04. You pay $10 for the whole package. Multiplying expected usage of 226,800 requests by that rate gives $9.072. That is the value of the used portion, not the purchase amount: the fixed package still cost $10.

Now assume that, after the additional attempts, the application completes all 216,000 scheduled checks. A thousand completed checks cost approximately $0.0463: $10 ÷ 216,000 × 1,000. This amount accounts for both extra requests and the reserve you purchased. If fewer checks are completed, divide the spending by their actual number.

The calculation works the same way for other tasks. With usage billing, multiply billable requests by the tariff rate, allowing for how many requests that rate covers. With a package, use its full purchase price. Then divide spending by the number of completed tasks. If several projects share a package, decide how to allocate its cost between them.

Also check whether the application can finish the work on time. Our example requires 7,200 checks per day, averaging five starts per minute. You could launch all 150 checks together every half hour or spread them across the interval. Package usage would be the same if each check took the assumed number of attempts, but the load at launch would differ. A connection limit or request-rate limit may prevent the first schedule from running as planned.

How to reduce unnecessary requests

Remove duplicate addresses and save results as the work progresses. After a failure, the application should continue from where it stopped. If it restarts the whole list each time, pages already processed consume the package again. Keep a record of which tasks are complete and which still need processing.

Use the loading method needed to retrieve the data. If the required text is already in the server response, running a browser may be unnecessary. If data appears only after scripts execute, a simple download may not be enough. With data collection services, browser mode and extra features sometimes use more credits or have another rate. One credit therefore does not always equal one request.

Reducing response size does not always save requests. If the provider counts HTTP calls, a short response may use as many requests as a long one. To reduce the count, you can check unchanged data less often, reuse a saved result, or retrieve several records in one API call. The information must still be fresh enough for your task.

Limit retries and consider why the request failed. If a website is temporarily unavailable or asks you to slow down, an immediate retry may return the same response and spend another request. Pausing or reducing the frequency can be more useful. Take particular care with actions that create or change data: check the result of the first attempt before submitting again. A lost response does not mean that the server did nothing.

After making changes, check the results as well as usage. The request count may have fallen because the application stopped doing part of the job. A reduction is useful when you still get the required data, with the same completeness and timeliness, using fewer requests.

What to check when choosing a tariff

First, make sure the service works for your websites and application. Proxy type, available countries, session behaviour, and access to the required pages through the supplied IPs all matter. Then compare the work included: who loads the page, runs the browser, extracts data, and retries failed attempts? This helps explain why two services charge different prices per request.

Check the package validity period, top-up rules, and treatment of unused requests. A large package with a lower request price is good value if you can use it for needed work in time. If some purchased requests go unused, the cost per completed task may be higher than with a smaller package.

For a comparison, select typical pages from your project, including ones that usually cause difficulty. Record the time spent, requests used, results obtained, and application settings. This test will indicate the package size you need, the approximate cost of the work, and whether you can finish it on time.