> ## Documentation Index > Fetch the complete documentation index at: https://developers.flameproxies.com/llms.txt > Use this file to discover all available pages before exploring further. # Core Concepts > How FlameProxies is organized. Understand packages, sub-users, parameters, sessions, pools, and modes so you can get the most out of the network. 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](/dashboard/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](/dashboard/sub-users). ## Parameters Everything about how a request is routed goes in the proxy **username**, after your package username. Parameters are separated by hyphens: ```text theme={null} -package-standard[-country-][-city-][-pool-1|2][-mode-fast][-mode-udp][-session--time-] ``` 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: ```text theme={null} package-standard # residential package-premium # premium residential ``` ### Location: where should the IP be? `country` and `city` limit the eligible IPs to one location: ```text theme={null} country-us-city-newyorkcity ``` Countries use lowercase two-letter codes. See [Locations](/proxies/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: ```text theme={null} pool-2-mode-fast ``` ### Session: how long should the IP stay the same? `session` and `time` hold the same IP across requests for a number of minutes: ```text theme={null} session-a1b2-time-30 ``` These groups combine freely in a single username: ```text theme={null} -package-standard-country-us-city-newyorkcity-pool-1-mode-fast-session-a1b2-time-30 ``` 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](/proxies/residential#full-parameter-reference) 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--time-` and every request with that session ID reuses the same IP for up to that many minutes: ```text theme={null} -package-standard-country-us-session-a1b2-time-30: ``` 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. | Mode | Parameter | What it does | | - | - | - | | Fast | `mode-fast` | Routes through the peer with the lowest latency available. Fast mode doesn't cost any extra bandwidth. | | UDP | `mode-udp` | Enables UDP traffic through the proxy. UDP is carried over SOCKS5, so connect on port `1080`. | ## 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: | Format | Layout | | - | - | | `standard` | `host:port:username:password` | | `secondary` | `username:password@host:port` | | `http_url` | `http://username:password@host:port` | | `socks5_url` | `socks5://username:password@host:port` | 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 Make your first request in under 5 minutes. Full parameter reference for residential proxies. Clean, high-trust IPs for strict anti-bot targets. How to set up credentials and connect.