Skip to main content
With FlameProxies, you don’t manage lists of IPs. You describe what you need in the proxy username — which product, where to exit, how long to keep an IP, how fast it should be — and the gateway picks a matching IP for every request. This page explains the building blocks: packages, sub-users, parameters, sessions, pools, modes, and output formats.

​
Packages

A package is your entry point to the proxy network. It’s where your credentials and bandwidth live. Each package has its own:
  • Product — residential or premium residential.
  • Username and password for authentication.
  • Bandwidth in GB. Bandwidth never expires.
When you buy bandwidth on the website, it’s added to your main package. Top-ups never create a new package; they increase the bandwidth of the package you already have. All usage is tracked per package, so you can see exactly how much traffic each package generates. See Usage analytics.

​
Sub-users

A sub-user is a separate package carved out of your main package. It has its own username and password, and its own bandwidth allocation, which is deducted from the main package. For example, if your main package has 10 GB and you create 3 sub-users with 1 GB each, the main package is left with 7 GB. Sub-users let you separate teams, customers, or workloads so that one can’t use up another’s bandwidth, and so that each one’s usage is tracked separately. Packages created through the Customer API are sub-users too. See Sub-users.

​
Parameters

Everything about how a request is routed goes in the proxy username, after your package username. Parameters are separated by hyphens:
Square brackets mark optional parameters. The parameters fall into four groups, and each answers a different question.

​
Package: which product?

package is the only required parameter. It selects the product your request uses:

​
Location: where should the IP be?

country and city limit the eligible IPs to one location:
Countries use lowercase two-letter codes. See Locations for every country and city.

​
Pool and modes: how should the IP be picked?

pool limits the request to one sub-pool of the network, and mode changes how the connection behaves:

​
Session: how long should the IP stay the same?

session and time hold the same IP across requests for a number of minutes:
These groups combine freely in a single username:
That username says: use residential proxies, exit from New York in the United States, draw only from sub-pool 1, route through the lowest-latency peer, and keep the same IP for 30 minutes under the session ID a1b2. The full list of parameters is in the Residential proxies reference.

​
Sessions

A session decides whether consecutive requests share an IP. Without a session, every request is independent. The gateway picks a new IP each time, with no memory of what happened before. This is rotating mode, and it’s the right choice for high-volume work where you don’t need IP continuity. Many workflows need continuity, though. You might need to log in, navigate to a page, and then scrape it from the same IP. That’s what sticky sessions are for. Add session-<id>-time-<minutes> and every request with that session ID reuses the same IP for up to that many minutes:
You pick the session ID. Use letters and digits, and don’t use hyphens, because hyphens separate parameters. To get a new IP before the time is up, switch to a new session ID. To run many sticky sessions in parallel, give each one its own ID.
Residential IPs belong to real devices on real home connections. A device can occasionally go offline before your session time is up, which means the session gets a new IP. Build multi-step workflows so they can recover from an unexpected IP change.

​
Pools

The residential network is split into sub-pools, each with its own performance characteristics. By default, the gateway draws from the whole network. Add pool-1 or pool-2 to restrict a request to a single sub-pool. If a target performs poorly, try each pool and compare the results — different targets often perform best on different pools.

​
Modes

Modes change how the gateway handles your connection. You can use one, both, or neither.

​
Output formats

Once you have a host, port, username, and password, different tools expect them in different layouts. The dashboard and the Customer API can output any of these: When you use SOCKS5 with URL output, use the socks5_url layout.

​
How it all fits together

  1. Your account has a main package that holds your bandwidth.
  2. You can split that bandwidth into sub-users, each with its own credentials.
  3. Every request authenticates with a package’s username and password.
  4. Parameters in the username choose the product, location, pool, and modes.
  5. With a session, the gateway keeps the same IP for the time you set. Without one, every request gets a new IP.
  6. The traffic you send is deducted from the bandwidth of the package you authenticated with.
The result is a system where you describe behavior, not infrastructure. You don’t need to know which specific IP you’re using — you set the parameters, and the gateway does the rest.

​
Next steps

Quickstart

Make your first request in under 5 minutes.

Residential proxies

Full parameter reference for residential proxies.

Premium residential proxies

Clean, high-trust IPs for strict anti-bot targets.

Authentication

How to set up credentials and connect.