Proxy team access: organizations, roles and API keys

Proxy team access in ProxyForge works through organizations: a shared account with its own proxies, orders and prepaid wallet, where each member signs in with their own login and holds one of three roles. Owners control members, billing, API keys and settings; Users buy and manage proxies against the shared wallet; Read only members can see proxies, orders and the balance but change nothing. Nobody passes a password around, and removing a person removes their access immediately.

This guide covers setting one up, choosing roles, funding the wallet, automating with API keys and webhooks, and the access patterns that hold up under a security review.

Why a shared login is the wrong way to share proxies

The quickest way to give a team proxy access is one account and one password in a shared vault. It works until someone leaves, when you have to change a password that is embedded in every teammate's browser and every script. It also leaves nothing to audit: every purchase and every configuration change was made by "the account".

An organization gives you proxy team access without that trade-off, because it separates the two things a shared login conflates:

• Who can act in the dashboard. Each member has their own login, and their role decides what they can do.
• What owns the proxies and the money. The organization owns its proxies, orders and wallet. People come and go; the assets stay put.

Proxy credentials, the username and password or allowlisted IPs your code uses to reach the gateway, are a third thing. They authenticate traffic, not people. Keep them in a secrets manager rather than in anyone's head, as described in storing proxy credentials, and consider IP allowlisting for servers with fixed egress addresses; IP allowlist vs username and password compares the two.

Creating an organization

1. Sign in to the dashboard and open Organizations.
2. Choose Create an organization and give it a name. Most teams use the company or team name. You can rename it later, but two organizations cannot be merged, so one per team is usually right.
3. You become its Owner. Creating an organization does not switch you into it: you keep working in your current account until you switch.
4. Switch to the new organization from the organizations list or the account switcher. You work in one organization at a time, and everything you buy while it is active belongs to it.
5. Under Settings, add invoice details: company name, VAT number and billing address. They are printed on every invoice billed to the organization.

The organization's wallet starts at zero and is separate from your personal balance. Funds do not move between them.

Adding members

Owners manage members from the organization's Members tab:

1. Ask the person to create their own ProxyForge login if they do not have one. A member is added by the email address on an existing account.
2. Choose Add member and enter that email address.
3. Pick a role. You can change it at any time.

Access is immediate; there is nothing for the new member to accept. The next time they sign in, the organization appears in their account switcher, and their own personal account is untouched. If the dashboard reports that nobody has an account with that email, the person has not signed up yet, or signed up with a different address.

The member list shows each person's name, email, role, the date they were added and when they were last seen. The last-seen column is the one to use in periodic access reviews: an account that has not been used in months is a candidate for removal.

Owner, User and Read only: choosing roles

Every member holds exactly one of three roles:

Owner can do everything: members, billing, cards, API keys, webhooks and the organization's own settings. Only Owners can open the organization's settings and member list.

User is the working role. Users buy proxies and manage them and their orders, and can see the wallet, so they know what they have to spend. They cannot add funds, and cannot touch members, cards, API keys or settings. This is the right role for engineers who run scraping jobs, manage rotation settings or order ISP addresses for a new project.

Read only sees proxies, orders and the wallet balance, and changes nothing. It suits finance, procurement, auditors, and managers who need visibility without the ability to spend.

An organization must always have at least one Owner. The dashboard refuses to demote or remove the last one.

The shared wallet: who funds it and who spends it

Each organization has one prepaid wallet. Purchases by any Owner or User draw from it, and everyone in the organization can see the balance. Only Owners can add funds, which gives you a clean split of duties: the people who hold the budget fund the wallet, and the people who do the work spend from it without being able to top it up themselves.

A few practices make this work in a team:

• Decide who funds the wallet and how often. With pay-as-you-go billing there is no monthly commitment, so a running job stops when the balance runs out. Name the Owner responsible for keeping it funded, and agree a threshold at which Users tell them.
• Watch the balance as a metric. Treat a falling balance like any other capacity signal. Proxy monitoring covers what to track alongside it.
• Use one organization per budget. If two teams must account for spend separately, give each its own organization, with its own wallet and invoice details, rather than reconciling one shared balance after the fact.

Rates are published on the pricing page. Volume customers can arrange Net-30 invoicing through sales.

API keys and webhooks for automation

API keys

API keys let your own code place orders, manage proxies and read usage through the API instead of the dashboard. Owners generate them from API keys. Each key is a pair: a key and a secret.

What to know before you rely on them:

• Generate one pair per integration. Keys have no name, scope or expiry of their own, so separate pairs are how you retire one integration without touching the others. Keep a record of which system holds which key.
• Treat the secret like a password. The dashboard shows it masked, with a reveal toggle, and it can be copied again later. Anyone who can open the API keys page as an Owner can read it, which is another reason to keep the number of Owners small.
• Deleting a key is immediate and final. Anything using it stops working at once, and the key cannot be restored. To rotate, generate the new pair, deploy it, then delete the old one.
• Generating a key requires a verified email address on the account.

Store the pair in the same secrets manager as your proxy credentials, never in a repository.

Webhooks

Webhooks let the platform tell you when something changes, such as a proxy activating, an expiry or a status change, so you do not have to poll. Owners add an endpoint URL that accepts JSON POST requests.

Every request is signed with the endpoint's signing secret, and your endpoint should verify the signature before trusting a payload; an endpoint that skips the check accepts anything anyone posts to it. The secret is shown once, when the webhook is created, and again each time it is rotated. Rotating it stops the old secret verifying immediately, so deploy the new one promptly. Each webhook keeps a delivery log showing what was sent, what your endpoint answered and how many attempts it took, with options to retry a delivery or send a test event.

Least-privilege patterns that pass a security review

Proxy team access is access to spend and to outbound traffic from addresses associated with your company. Reviewers will ask how it is controlled; the proxy vendor security questionnaire lists the questions they tend to ask. These patterns give you good answers:

• Keep Owners few, but not one. Two Owners, typically a budget holder and a technical lead, means ownership never depends on one person's availability. Everyone else should be a User or Read only.
• Default to Read only. Give Read only to finance, procurement, auditors and anyone who asked "can I see it?". Promote to User when someone needs to buy or configure, not before.
• Assume visibility is usable. Every role, Read only included, can see the organization's proxies and their connection details, and a connection string a person can read is one they can use. Keep production credentials in a secrets manager, and prefer IP allowlisting for production servers so that a copied password alone does not grant access.
• Separate automation from people. Give each automated system its own API key pair rather than letting it use a person's session, so removing a person never breaks a pipeline and deleting a key never locks out a person.
• Review quarterly. Go through the member list, check roles against current job functions, remove anyone not seen in months, and delete API keys whose integration no longer exists.

Offboarding a member

When someone leaves the team or no longer needs access:

1. Remove them from the organization. They lose access to the organization and everything it owns immediately. Their personal account is untouched, and so are the proxies and orders they bought for the organization.
2. If they were an Owner, promote a successor first. Change another member's role to Owner, confirm it, then remove or demote the departing Owner. The dashboard will not remove the last Owner, and handing over ownership is always these two steps.
3. Review the credentials they could read. If they were an Owner, generate new API key pairs for the integrations they had access to, deploy them, and delete the old ones. Rotate the signing secret of any webhook whose secret they handled.
4. Check the systems they administered. Proxy credentials stored in scripts, CI variables or personal machines they managed should be moved into your secrets manager or replaced.
5. Record it. Note the date and what was changed, so the next access review has something to check against.

Setting up your team on ProxyForge

Organizations, roles, the shared wallet, API keys and webhooks are available on every ProxyForge account and apply across all four proxy lines listed on the products page. Create the organization first, add your Owners and Users, fund the wallet, and then generate API keys for the systems that need them.

If your procurement or security team needs more than this page covers, such as our sourcing audits, DPA or KYC process, the due diligence checklist sets out what to ask, and our team can answer it directly.