Automation with proxies: scripts, bots and no-code tools without hiccups

A proxy isn't switched on “for the whole workflow”: it applies to the requests that use it. That's why it has to be set exactly where they start.

• Scripts (Python, Node.js, cURL): the proxy is passed to the HTTP library. Ready-made examples in the Python and Node.js guides.
• Automated browsers (Playwright, Puppeteer, Selenium): the proxy is passed at browser launch, as in the Playwright guide.
• n8n: in the HTTP Request node, under Options › Proxy, or for the whole instance with the HTTP_PROXY and HTTPS_PROXY variables. Step by step in the n8n guide.
• Make: the latest version of the HTTP module includes proxy settings, earlier ones don't. Check which module version you're using.
• Zapier: Webhooks by Zapier has no proxy field. For requests that must go through the proxy, people usually add a Code by Zapier step in Python, where the requests library accepts a proxy.

Automations come in two kinds. Those that work on an account (posting, running a store, pulling reports from a dashboard) need continuity: the same IP for the whole session, always from the same country. Those that collect public data (prices, stock, results) benefit from changing IP between rounds.

If you use the same proxy for both, data-collection rotation changes the account's IP mid-session. The fix is simple: one stable proxy for accounts and one with rotation for data. The reasoning is explained in IP rotation.

• Rotation link: a GET request to the proxy's link, no key needed. It replies with the new IP as soon as the change is complete, usually within seconds: you can carry on straight away.
• API: with a key created under Settings → API you can change IP, read the current IP, renew the proxy and set automatic rotation from your scripts. Docs and examples in ProxyHub API.
• Automatic rotation: pick an interval (from 5 minutes to 24 hours) and the IP changes on its own, with no code.

1. Check the IP at start-up: a request to a service such as api.ipify.org confirms traffic goes through the proxy before you begin. How to do it in How to test a proxy.
2. Steady pacing: pauses between requests, small batches and spread-out schedules instead of concentrated bursts.
3. Retries with growing waits: for timeouts, 429 and 503, retry after 5, 10, 20 seconds, not straight away. A request cut off by an IP change simply needs repeating.
4. Generous timeouts: a mobile network can have latency spikes; 30 seconds is a good starting point.
5. Essential logs: IP used, response code and timings. They tell you straight away whether the problem is the proxy or the site.
6. Keep credentials safe: username, password and API key in environment variables or in the tool's credential store, never in shared code.

For data collection, the full method with sample code is in Web scraping with proxies. The terms of use of sites and platforms apply to automated workflows too.