Automated Monitoring of Government Procurement and Tenders via Proxy: Setup Without Blocks

Manual monitoring of tenders on the EIS platforms (Zakupki.gov.ru), Sberbank-AST, and RTS-tender takes 3-5 hours daily. Automation through parsers solves the problem, but government platforms actively block automated requests — IPs get banned after 50-100 requests. Proxies allow you to bypass restrictions and collect data on new tenders around the clock without the risk of blocking the company's main IP.

In this guide, we will discuss: which proxies are suitable for different tender platforms, how to set up automatic parsing without blocks, which ready-made tools to use, and how to avoid common mistakes that lead to bans.

Why Tender Platforms Block Automated Requests

Government and commercial tender platforms use multi-layered protection against automated data collection. This is due to several reasons: the load on servers from parsers can reach 60-70% of total traffic, competitors use collected data for dumping, and there are requirements for protecting the personal data of procurement participants.

The Unified Information System (EIS) is the most secure platform. The system records the following parameters of each request: IP address, browser User-Agent, request frequency, and sequence of actions on the site. If more than 100 requests per hour come from one IP or if requests are made too evenly (for example, every 5 seconds), the IP is blocked for 24-72 hours. The block applies to the entire subnet range, so the whole company may be affected.

Commercial platforms (Sberbank-AST, RTS-tender, Fabrikant) use softer protection but also monitor suspicious activity. The main triggers for blocking include: absence of cookies, disabled JavaScript, excessively fast navigation between pages (less than 2 seconds per page), and identical time intervals between requests.

Which Type of Proxy to Choose for Monitoring Tenders

Three types of proxies are suitable for monitoring tender platforms, each with its own application features. The choice depends on the volume of parsing, budget, and reliability requirements.

Residential proxies are the optimal choice for most tender monitoring tasks. They use IP addresses of real home users, so platforms perceive requests as actions of ordinary people. For EIS, it is recommended to use Russian residential proxies with rotation every 10-15 minutes. This allows collecting data on 500-1000 tenders daily without a single block.

Datacenter proxies are suitable for less secure commercial platforms: RTS-tender, Fabrikant, B2B-Center. They are 3-5 times cheaper than residential proxies and work faster, but EIS often recognizes and blocks such IPs. Use them for initial testing of the parser or monitoring small regional platforms.

Mobile proxies have the highest level of trust, as they use IPs from mobile operators (MTS, Beeline, MegaFon). Platforms almost never block such addresses because thousands of real users can be behind one operator's IP. The downside is the higher cost. Use mobile proxies if you are working with particularly valuable tenders or have already experienced blocks when using residential proxies.

Features of Protection on Different Platforms: EIS, Sberbank-AST, RTS-tender

Each tender platform has its own protection features against parsing. Understanding these mechanisms allows you to configure the parser to minimize the risk of blocking.

EIS (Zakupki.gov.ru) — Maximum Protection

The Unified Information System uses the strictest protection among all platforms. The main mechanisms include: a limit of 100 requests per hour from one IP, mandatory support for cookies and JavaScript, referrer checking (where the user came from), and behavioral analysis (time on page, mouse movement, scrolling).

Recommendations for parsing EIS: use residential or mobile proxies with Russian IPs, enable automatic proxy rotation every 80-90 requests (to avoid reaching the limit), add random delays between requests from 3 to 8 seconds, and use headless browsers (Puppeteer, Selenium) instead of simple HTTP requests — they fully emulate the behavior of a real browser.

Sberbank-AST — Medium Level of Protection

The Sberbank platform uses softer restrictions: a limit of about 200-300 requests per hour, cookies are mandatory, but JavaScript is not always checked, and blocking occurs with obviously robotic behavior (identical intervals between requests, absence of referrer).

For Sberbank-AST, residential proxies with rotation every 200 requests are sufficient. You can use simpler parsing tools without full browser emulation, but be sure to add random delays of 2-5 seconds and correct User-Agent headers.

RTS-tender, Fabrikant, B2B-Center — Basic Protection

Commercial platforms have minimal protection: limits of 500+ requests per hour, the main checks are the presence of cookies and an adequate User-Agent, and they rarely block datacenter proxies.

For these platforms, even datacenter proxies with basic rotation are suitable. You can use simple HTTP parsers without browser emulation. The main thing is not to send requests too frequently (minimum 1-2 seconds between requests) and to periodically change IPs.

Ready-made Tools for Parsing Tenders Without Programming

For monitoring tenders, it is not necessary to write code from scratch. There are ready-made solutions with a graphical interface that support working through proxies.

Octoparse — a visual parser with proxy support and a task scheduler. It allows you to create a parser for any tender platform through a graphical interface: you simply click on the elements of the page that need to be collected (tender number, customer, amount, application deadline), and the program automatically creates the parsing algorithm. In the settings, you can specify a list of proxies, and Octoparse will automatically rotate them. The cost starts from $75/month, with a free version that has limitations.

ParseHub — an alternative to Octoparse with a simpler interface. It is well-suited for beginners. It supports JavaScript sites (important for EIS), works through proxies, and exports data to Excel/Google Sheets. The free version allows you to create up to 5 parsing projects. The paid version starts at $149/month with the ability to run parsing on a schedule (for example, checking for new tenders every 2 hours).

Screaming Frog SEO Spider — originally an SEO tool, but excellent for parsing structured data. It supports proxies and can collect data from pages based on specified CSS selectors. The downside is that you need to understand the HTML structure of pages a bit. The cost is £149/year (about 15,000 rubles), which is cheaper than alternatives.

Specialized Tender Monitoring Services — Kontur.Zakupki, Tender.Pro, B2B-Center already have built-in monitoring systems with filters and notifications. They do not require proxy setup, as they operate on behalf of the service. The cost ranges from 5,000 to 30,000 rubles per month depending on the number of tracked categories. The downside is that you depend on the service's capabilities and cannot collect additional data or integrate it into your CRM.

Step-by-Step Setup of Monitoring via Proxies in 20 Minutes

Let's consider the setup of automatic tender monitoring using Octoparse — one of the most popular tools with a graphical interface. This example is suitable for monitoring EIS, Sberbank-AST, and other platforms.

Step 1: Obtain Proxies. Register with a proxy provider and get a list of IP addresses with ports and authentication data. For monitoring EIS, at least 10 residential Russian proxies with automatic rotation are recommended. The provider will provide the data in the format: IP:PORT:USERNAME:PASSWORD (for example, 185.123.45.67:8000:user123:pass456).

Step 2: Install and Configure Octoparse. Download Octoparse from the official website and install it on your computer. After launching, create a new parsing project by entering the URL of the search results page for tenders on EIS (for example, searching for the keyword "equipment" in your region).

Step 3: Configure Proxies in Octoparse. Open Settings → Proxy Settings. Select the "Use custom proxy" mode. Add your proxies to the list, specifying the IP, port, type (HTTP or SOCKS5), username, and password. Enable the "Rotate proxy for each request" option — this will make the program change the proxy after each request, distributing the load and avoiding blocks.

Step 4: Create the Parsing Algorithm. In visual mode, click on the elements of the page that need to be collected: procurement number, name, customer, starting price, application deadline, region. Octoparse will automatically determine the data structure and create the collection algorithm. Check the result on the first 5-10 records — the program will show a preview of the parsing result.

Step 5: Set Up Pagination. Tender platforms display results page by page (usually 10-50 tenders per page). In Octoparse, add the action "Click pagination button" and specify the "Next page" button. The program will automatically navigate through the pages and collect all results.

Step 6: Add Delays. In the parser settings, set random delays between requests: a minimum of 3 seconds, a maximum of 8 seconds. This simulates the behavior of a real user and reduces the risk of blocking. Also, add a delay of 5-10 seconds after loading each page — this allows time for JavaScript elements to fully load.

Step 7: Set Up a Schedule. In the "Task Schedule" section, configure automatic parsing launch. For monitoring new tenders, it is optimal to run checks every 2-4 hours during working hours. For example: 9:00, 13:00, 17:00, 21:00. This will allow tracking new publications throughout the day without overloading the platform.

Step 8: Export Data. Set up automatic export of collected data in a convenient format: Excel, Google Sheets, MySQL database, or sending via API to your CRM system. Octoparse can automatically send new data after each parser run, allowing you to receive notifications about new tenders in real time.

Setting Up Proxy Rotation and Delays Between Requests

Properly configuring proxy rotation and delays is a key factor for successful parsing without blocks. Even with quality proxies, incorrect configuration will lead to bans.

Proxy Rotation Strategies: There are three main approaches to changing IP addresses during parsing.

Rotation after each request — the safest but slowest method. Each request to the platform goes from a new IP. Suitable for EIS when parsing large volumes of data (1000+ tenders). The downside is that it increases parsing time, as establishing a new connection through a proxy takes 200-500 ms.

Rotation by number of requests — an optimal balance of speed and security. One proxy is used for 50-100 requests, then switched to the next. For EIS, it is recommended to change proxies every 80 requests (slightly below the limit of 100). For commercial platforms, you can increase it to 200-300 requests per IP.

Time-based rotation — changing IP every 10-15 minutes regardless of the number of requests. Suitable for long-term parsing with low intensity (for example, monitoring updates throughout the day). Some proxy providers offer automatic time-based rotation — you receive one proxy URL, but the IP changes automatically every N minutes.

Setting Delays Between Requests: A person cannot instantly switch between pages — they need time to read, scroll, and click. The parser should simulate this behavior.

It is important to use random delays within the specified range. If the parser makes requests exactly every 5 seconds, the protection system will easily identify a bot. The random delay function is available in all popular parsing tools.

Common Mistakes That Lead to Blocking

Even when using quality proxies, a parser can get blocked due to technical errors in configuration. Here are the most common problems and how to solve them.

Mistake 1: Using the Same User-Agent. The User-Agent is a string that informs the site about the browser and operating system being used. If all requests come with the same User-Agent (for example, the standard one for the Python requests library), this is a clear sign of a bot. Solution: use a list of 10-20 popular User-Agents for different browsers (Chrome, Firefox, Safari) and operating systems (Windows, macOS, Linux), and rotate them randomly with each request.

Mistake 2: Disabled Cookies. Most sites set cookies on the first visit and check for their presence on subsequent requests. If the parser does not save cookies, each request appears as a first visit from a new device, which is suspicious. Solution: enable cookie support in the parser settings. In Octoparse and ParseHub, this is done automatically. If you are writing your own parser in Python, use the requests.Session() library — it automatically saves cookies between requests.

Mistake 3: Parsing Without Executing JavaScript. Modern sites, including EIS, actively use JavaScript to load content. If the parser simply downloads the HTML code of the page without executing JavaScript, it will receive incomplete data, and the server will register suspicious behavior. Solution: use headless browsers (Puppeteer, Selenium, Playwright) that fully load the page, execute JavaScript, and can even scroll the page to load dynamic content.

Mistake 4: Ignoring Captchas. Some platforms display a captcha when suspicious activity is detected. If the parser cannot solve the captcha, it will hang and start sending repeated requests, leading to IP blocking. Solution: use automatic captcha-solving services (2Captcha, Anti-Captcha) — they cost about $1-3 for 1000 solved captchas. Most parsing tools have built-in integration with such services.

Mistake 5: Parsing During Peak Load Hours. From 10:00 AM to 4:00 PM on weekdays, tender platforms experience maximum user activity, and protection systems operate most strictly. Intensive parsing during this time will more quickly lead to blocking. Solution: run the main volume of parsing in the evening (6:00 PM - 11:00 PM) or at night. During working hours, only perform targeted checks for new tenders with minimal intensity.

Mistake 6: Using "Dirty" Proxies. Some cheap proxy providers sell IPs that have already been used for spam or other suspicious activities and are on blacklists. Solution: test proxies before mass use. Send 20-30 test requests to the platform from each new proxy and check if a captcha or block occurs. If the proxy is "dirty," replace it with the provider.

Scaling: Monitoring 10+ Platforms Simultaneously

Once basic monitoring of one or two platforms is set up and working stably, the task of scaling arises — simultaneous parsing of dozens of tender platforms to achieve maximum market coverage.

Distributing Proxies Among Platforms. Do not use the same proxies for different platforms simultaneously. Create proxy pools: for example, 10 proxies for EIS, 5 for Sberbank-AST, 5 for RTS-tender, and so on. This will prevent a situation where a block on one platform affects the parser's operation on another.

Prioritizing Platforms. Not all tender platforms are equally important for your business. Identify 3-5 key platforms where the most relevant tenders are published and allocate more resources to them: the best proxies, more frequent checks, and more detailed parsing (including collecting documentation). For other platforms, use basic monitoring of only the main tender parameters.

Automating Data Processing. When parsing 10+ platforms, you will receive hundreds of new tenders daily. Manual processing is impossible. Set up automatic filtering: by keywords in the tender title, by the customer's region, by the range of starting prices, by the application deadline. Only tenders that pass all filters go into the list for manual review.

Integration with CRM and Notification Systems. Set up automatic sending of filtered tenders to your CRM system or corporate messenger (Slack, Telegram, Microsoft Teams). Managers will receive notifications about new suitable tenders in real time and can quickly decide on participation.

Monitoring Parser Performance. When working with multiple platforms, it is critically important to track the status of each parser. Set up a dashboard that shows: when each parser was last run, how many tenders it collected, and whether there were any errors or blocks. Tools like Octoparse have built-in dashboards. If you are using your own scripts, you can set up logging in Google Sheets or specialized monitoring systems like Grafana.

Conclusion

Automating the monitoring of government and commercial tenders via proxies allows you to receive information about new procurements in real time, saving up to 4 hours daily on manual searches and increasing the number of submitted applications by 30-50%. Key success factors: the right choice of proxy type depending on the platform, correct configuration of IP rotation and delays between requests, and the use of tools that support JavaScript and cookies.

For monitoring protected platforms like EIS, use residential or mobile proxies with Russian IP addresses — they provide the highest level of trust and the lowest risk of blocks. For commercial platforms with basic protection, more affordable datacenter proxies will suffice. Start by automating 2-3 key platforms, refine your settings, and then scale the system to cover the entire tender market in your industry.

If you plan to set up round-the-clock monitoring of tender platforms, we recommend using residential proxies — they ensure stable operation of parsers without blocks even with high request intensity to protected government platforms.