Residential proxy

Package — your subscription (traffic limit + expiration). List — a named login/password bundle with geo and whitelist filters that lives inside a package. Session — short-lived binding of a specific exit IP to a single connection, formed on-the-fly via _s_… suffix on the login.

At the package level. A list is just credentials and a filter; consumption-cost aggregates by login (i.e. per list) but actual debits hit the package pool.

Each port gives an independent exit IP — use them in parallel for concurrent requests. One port = one exit IP at a given moment.

A list inside your main package gives you a credentials/filter bundle — but its traffic shares the package's pool with no cap. A subpackage carves out a fixed slice of traffic (traffic_limit) with its own expiration and on/off toggle, returning unused traffic to the parent on deletion. Lists you create inside it work the same way — they're just billed against the subpackage's slice.

Use a subpackage when you need a hard traffic cap for someone (a client, a team, a campaign) — without giving up your API key. All management still happens through your own key. Use a plain list when you only need credential or geo isolation within your own quota.

Yes: https://proxy-seller.com/personal/api/v1/{YourApiKey}/resident/.... Subuser variants use /residentsubuser/....

HTTP and SOCKS5 over the same IP.

Programmatic renewal of a residential package isn't covered in the public API. /extend-proxies (/prolong/calc/{type}, /prolong/make/{type}) accepts only IP-based types — ipv4, ipv6, mobile, isp, mix, mix_isp. resident is not in that list and there is no /resident/prolong endpoint.

Renew the residential package via the dashboard before expired_at reported by get-package-information. The exact behaviour at expiration (active connections, unused traffic carry-over) isn't documented in the API spec — verify with support if it matters for your integration.