The same proxy pool can be used in different ways: automatically changing the IP every N minutes or manually triggering the address change via API at the moment of action. The difference may seem like a technical detail, but it determines whether you will get your account banned or enjoy clean data collection without blocks. We discuss when timer-based rotation is needed and when controlled IP change via API is required, analyzing 6 real-world scenarios.
Timer-based Rotation vs IP Change via API: The Difference
Timer-based rotation is the automatic change of the IP address at a specified interval: once every minute, once every 10 minutes, or once an hour. The proxy provider changes the exit node itself, and you simply continue to send requests through the same port or endpoint. This is convenient when the exact moment of IP change is not important — the main thing is that the address is updated regularly and you do not "get stuck" on one IP for too long.
IP change via API is a manual or programmatic request to change the address exactly when you need it: after an error, after a captcha, before a new scraping session, or before launching a new advertising account. You send a GET or POST request to a special URL of the provider — and receive a new IP on demand, without being tied to a timer.
The key difference: the timer operates "on schedule" and does not react to the context of the task, while the API provides full control — you decide exactly when a new IP is needed. For some tasks (scraping a large volume of pages), a timer is more convenient; for others (account farming, where it is important to link one IP to one profile), only the API or a static session without rotation at all will suffice.
Comparison Table: What to Choose
| Criterion | Timer-based Rotation | IP Change via API |
|---|---|---|
| Control Over Change Timing | No, only interval | Full, on request |
| Suitable for Account Farming | Poor — breaks session | Good — change between sessions |
| Suitable for Scraping | Good — auto-bypass limits | Good if response to captcha is needed |
| Requires Code/Script | No, set up once | Yes, minimal request to URL |
| Risk of Breaking Active Session | High | Low, if called manually |
Scenario 1: Facebook Ads and TikTok Ads Account Farming
Here, timer-based rotation is a direct path to a ban. Facebook and TikTok analyze the stability of the IP address throughout the account's life: if the IP jumps every 10 minutes, the system perceives this as a sign of a bot or hacking. The correct scheme is one static IP per account, with no rotation at all, or an IP change via API only at the moment of creating a new profile or when moving the account to another location.
In anti-detect browsers like Dolphin Anty, AdsPower, or Multilogin, each profile is assigned a separate proxy port. When using static residential proxies with session binding, the IP does not change until you request a new one via API — for example, in case of a ban or when scaling to a new batch of accounts. For this task, residential proxies with a long session (sticky session) are well-suited — they appear as regular home internet and do not raise suspicions with anti-fraud systems.
Scenario 2: SMM Automation in Instagram and TikTok
SMM agencies managing 20-50 client accounts face a similar problem: each account must have its stable IP, tied for weeks or months. Timer-based rotation disrupts the behavioral profile here — Instagram sees the change in geolocation within one session and imposes a shadow ban on posting or limits the reach of Stories.
The working practice is to assign a sticky session to each profile in the anti-detect browser and use the IP change API only when the account needs to be "refreshed" after a long downtime or after suspicion of a soft ban. Mobile proxies show the best results in this scenario, as mobile operator IPs are less likely to fall under the filters of social network anti-bot systems — this is especially important when working with TikTok, where the detection of multi-accounting is particularly strict.
Scenario 3: Price Scraping on Wildberries and Ozon
Here, the situation is the opposite: timer-based rotation is what you need. Wildberries and Ozon ban IP addresses based on the number of requests per unit of time, not on the behavior of a single session — they do not care whether the user is "live," but rather the frequency of requests. The optimal scheme is to rotate IPs every 30-60 seconds or after every N-th request to distribute the load among hundreds of addresses and avoid hitting the rate limit of a single IP.
For scraping marketplaces, it is optimal to combine both approaches: basic timer-based rotation for even distribution of requests, plus an API request for instant IP change upon receiving a captcha or HTTP 429. Data center proxies handle this task well with a high volume of requests, and for more sensitive cards, where Wildberries checks behavioral patterns, it is better to connect data center proxies with high speed and low cost per volume.
Scenario 4: Monitoring Ads on Avito
Avito strictly checks geography and frequency of actions from a single IP — especially when mass posting ads from different cities. If you are posting ads on behalf of several "sellers" in different regions, timer-based rotation is not suitable: the system sees that the IP jumps between cities within one activity and blocks the account due to suspicion of fake geolocation.
The correct approach is to change the IP via API strictly before starting a new session in the required region, followed by fixing the IP for the entire period of work with a specific ad or account. Residential proxies with geo-targeting by city provide exact compliance with the declared location of the seller, which is critical for passing Avito's verification.
Scenario 5: Creative Testing in Google Ads and Yandex.Direct
Marketers testing ads from different regions need predictable control over the IP: to see how the ad looks in a specific city or country, record the result, then switch to the next location. Here, timer-based rotation is meaningless — you need a specific country at a specific moment of the test.
The optimal scheme is to change the IP via API with a clear indication of the desired geolocation in the request. You send a request "give me an IP from Germany" — receive the address, check the ad display, then change to an IP from another country in the same way. This approach saves time compared to waiting for random timer-based rotation, which may yield an incorrect location needed for the test.
Scenario 6: Mass Web Scraping and Bypassing Rate Limits
For tasks with a high volume of requests — collecting thousands of pages per hour — timer-based rotation is integrated directly into the script as the main mechanism for bypassing blocks. Here, IP change via API is used selectively: as a reactive mechanism for specific HTTP error codes (403, 429, 503), when standard rotation has not acted in time.
An example logic in Python: if code 429 is received, the script immediately calls the IP change API, without waiting for the timer to expire. This is a hybrid model — it reduces the number of "dead" requests and saves traffic compared to purely timer-based rotation, where the change occurs blindly, regardless of the actual request result.
How to Set Up Rotation in Anti-Detect Browsers
In most anti-detect browsers, rotation is set at the proxy profile level, not at the browser level. The general algorithm for Dolphin Anty, AdsPower, and GoLogin looks like this:
- Open profile settings → "Proxy" section
- Select connection type: HTTP, SOCKS5, or built-in provider
- Insert the proxy provider's endpoint with the session parameter (sticky session ID)
- If timer-based rotation is needed — specify the interval in the provider's personal account (usually 1, 10, 30, or 60 minutes)
- If manual change is needed — save the API link for IP change separately and call it outside the browser via a simple GET request or an extension with a button
- Check the IP through the built-in profile checker before starting work
Important: for account farming, keep the same port/session tied to a specific profile for its entire lifespan — do not switch profiles between different IPs without explicit necessity, or you will create a pattern resembling suspicious activity.
Example of IP Change via API (Code)
For those automating scraping or testing via scripts, IP change via API is usually implemented with a single HTTP request. Below is an example in Python using the requests library:
import requests
import time
def rotate_ip(api_url, session_token):
response = requests.get(
api_url,
params={"token": session_token, "action": "rotate"}
)
if response.status_code == 200:
print("New IP:", response.json().get("ip"))
else:
print("Rotation error:", response.status_code)
def fetch_with_retry(url, proxy, api_url, session_token, max_retries=3):
for attempt in range(max_retries):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
if resp.status_code == 429:
print("Request limit reached, changing IP...")
rotate_ip(api_url, session_token)
time.sleep(2)
continue
return resp
except requests.exceptions.RequestException as e:
print("Request error:", e)
rotate_ip(api_url, session_token)
return None
The same principle is implemented via cURL for quick checks without writing a script:
curl "https://api.proxy-provider.com/rotate?token=YOUR_TOKEN&action=rotate"In Node.js, a similar request looks compact using the built-in fetch:
const rotateIp = async (apiUrl, token) => {
const res = await fetch(`${apiUrl}?token=${token}&action=rotate`);
const data = await res.json();
console.log("New IP:", data.ip);
};Common Mistakes When Choosing a Rotation Method
Error 1. Setting a short timer-based rotation (1-5 minutes) for Facebook account farming — result: mass bans within the first day after registration.
Error 2. Using a static IP without rotation for marketplace scraping — result: one IP quickly hits the rate limit, and the entire process stalls.
Error 3. Not checking the compatibility of geo-parameters with the API — requesting an IP without specifying the country, receiving a random location that does not fit the ad testing.
Error 4. Calling the IP change API too frequently without reason — this increases traffic consumption and does not provide an advantage over a well-configured timer.
Error 5. Not testing the new IP before starting work — an old session may "stick" to a blocked or already flagged address.
Conclusion
The choice between timer-based rotation and IP change via API depends not on which method is "better" overall, but on the specific task. For account farming and SMM automation, stability is important — one IP per profile, with rotation via API only when explicitly necessary. For scraping marketplaces and mass scraping, the reverse logic applies — frequent timer-based rotation with targeted changes via API upon errors. For marketing tests and geo-targeting — precise control via API with the specified country.
If you are working with account farming or managing client SMM profiles, consider residential proxies with sticky sessions — they provide a stable IP for a long time without the risk of breaking the profile. For scraping large volumes of data with frequent rotation, data center proxies are more suitable — they are faster and more cost-effective for traffic, and for mobile traffic in Instagram and TikTok, mobile proxies are effective, as they are less likely to fall under social network anti-bot filters.