How to Write a Proxy RFP Vendors Will Actually Answer

Write six sections and nothing else.

1. Workload statement. Monthly successful requests, average response size in KB, expected failure rate, peak concurrency, geographic split as percentages, session duration requirement, protocols, authentication method.
2. Commercial. Each vendor's native pricing model in their own units, plus one mandatory normalised line: cost per 1,000,000 successful requests at the payload and failure rate you stated.
3. Technical. Concurrency definition, session control, geo granularity, protocol support, rotation behaviour, failure billing, rate limits, API surface.
4. Provenance and compliance. Where the addresses come from, which ASNs, what the acceptable use policy forbids, what data the vendor logs and for how long.
5. Operations. Support hours, escalation path for a block, incident history, notice period, exit terms.
6. Trial. What you will test, against which of your own targets, for how long, and the numeric threshold that counts as a pass.

Publish your scoring weights inside the document. Set a response format. Then hold the line on both, because the vendor who ignores your format in a bid will ignore your ticket priority in production.

Four failures account for nearly all of it, and every one is fixable in the document rather than in the evaluation meeting.

The RFP asks for features, so it gets a feature list. "Do you support SOCKS5?" gets a yes from everyone and separates nobody. The useful version is "state the hostname and port for SOCKS5, and whether username and password authentication is available on that port." That one cannot be answered with a tick.

The RFP does not state the workload, so the vendor cannot price it. A per-GB vendor genuinely cannot quote you without knowing your average payload. Asked to guess, they either quote a headline rate that ignores your reality or quote high to be safe. Either way the bid is fiction, and the vendor is not at fault.

The RFP asks unfalsifiable questions. "How many IPs are in your pool?" is the canonical example. There is no auditor, no standard for what counts as an available address, and no consequence for an optimistic number. Our breakdown of proxy pool size claims covers why that number stopped meaning anything.

The RFP sets no response format, so comparison becomes manual archaeology. Three PDFs of different lengths, with prices in different units and no consistent labelling, take a day each to normalise. By the time you finish, the evaluation has quietly become "whoever wrote the clearest deck".

Write this first and spend the most time on it. Every other section derives from it, and vendors who receive a good one will tell you it is the first they have seen.

State these, in these units:

• Monthly successful requests. A single number. Say whether it grows and by how much.
• Average response size in KB, plus the 90th percentile. A per-GB bid is meaningless without it.
• Expected failure and retry rate as a percentage. This is the number that decides whether per-GB billing is cheap or brutal, because failed requests still transfer bytes.
• Peak concurrency, and your definition of it. State whether you mean TCP connections open, requests in flight, or logical sessions.
• Geographic split as percentages, not a list. "US 60%, DE 15%, JP 10%, BR 8%, remainder worldwide" is priceable. "Global coverage required" is not.
• Geo granularity. Country only, or state and city? City targeting narrows the vendor field sharply and costs more.
• Session requirement. Stateless per request, or a stable exit held for N minutes? Give the number.
• Protocols. HTTP, HTTPS via CONNECT, SOCKS5, and whether you need all three on one credential set.
• Authentication. Credentials, IP whitelist, or both. If your workers run in a cloud with rotating egress addresses, say so, because whitelist-only vendors are then disqualified on a technicality they would rather discover now.
• Target classes, not target names. "Large retail catalogs", "public search results", "government registries". Naming your actual targets in a document that goes to five vendors is a competitive disclosure you do not need to make.

Two lines that save an entire evaluation round: state your contract term tolerance (monthly, annual, multi-year) and your budget band. Vendors who cannot serve the band will decline early instead of consuming two weeks of everyone's time.

Let each vendor bid in their native model. Then force one derived number they must compute themselves.

Ask for the native bid. Per IP per month, per gigabyte, per concurrent thread, per credit, per successful request, whatever they sell. Ask for the full tier ladder rather than a single quote, because it shows where your growth lands.

Then require this line, verbatim, in every bid:

Cost per 1,000,000 successful requests, computed against the workload statement in Section 1, including retries at the stated failure rate, in USD per month excluding tax.

That single line does the work the rest of the document cannot. Here is why, using a workload of 4,000,000 successful requests a month, 120 KB average response, 15% failure and retry rate, 200 peak concurrency.

Total requests attempted, including retries: 4,000,000 times 1.15 is 4,600,000. Bytes moved: 4,600,000 times 120 KB is 552,000,000 KB, which at 1,000,000 KB per GB is 552 GB a month.

The spread is roughly fivefold, and almost none of it is vendor efficiency. It is the billing unit meeting your payload size. Change the average response to 20 KB and the per-GB bids collapse to a fraction of the flat one. Change the failure rate to 40% and the per-GB bids rise by more than a fifth while the flat bid does not move at all.

That is the entire argument for making vendors compute this line rather than computing it yourself: it forces each of them to state, on the record, what your workload costs in their model, and it makes the sensitivity visible to your finance team before signature rather than after. Our explainer on datacenter proxy pricing models covers how each model behaves as the workload shifts.

Three more commercial questions worth a mandatory answer:

• Do failed requests bill? Get a yes or no in writing, per billing unit. On a per-GB plan the honest answer is almost always yes.
• What happens at overage? Hard stop, throttle, or automatic purchase at a stated rate. Say which you require.
• What is the discount ladder, and at what commitment? Ask for it in the bid rather than negotiating it later, so the comparison includes it. Our notes on negotiating proxy volume discounts cover what is usually available.

Keep this short and make every question one that a marketing page cannot answer.

Define concurrency, in your words, and ask them to confirm or correct. "We define a concurrent connection as one TCP connection open to your gateway. Confirm whether your limit counts connections, in-flight requests, or sessions." This single definition can halve or double the plan you need, and vendors genuinely differ.

Session control. "State the mechanism and hostname or port for holding one exit address across multiple requests, and the maximum duration."

Rotation behaviour. "State whether rotation is per request, on a fixed interval, or configurable, and give the interval."

Geo targeting. "For each country in our split, state whether city-level targeting is available and how the city is determined."

Protocol endpoints. "Give the hostname and port for each supported protocol." A vendor with one gateway host and separate ports for HTTP, sticky sessions and SOCKS5 is telling you something about how the product is built.

Rate limits. "State any per-account, per-IP or per-endpoint request rate limit, and the HTTP status returned when it is hit."

API surface. "Describe programmatic access for credential rotation, sub-account creation, whitelist management and usage reporting." If your team cannot script provisioning, someone will end up managing it in a browser at 2am.

Observability. "What usage data is available, at what granularity, with what delay, and through what interface?" Billing disputes are won and lost on this.

This section is where you separate operators from resellers, and it is the one your legal team will read most closely.

Address origin. "For each product offered, state how the IP addresses are obtained: allocated to you by an RIR, leased, sourced from an SDK or application partner, or acquired from a third party."

ASN disclosure. "List the ASNs your exits announce from for our top three countries." This is answerable, checkable against public routing data, and far more informative than a pool size. Our explainer on subnet proxies covers why prefix diversity matters more than address count.

Consent, for anything residential. "If any product routes through end-user devices, describe the consent mechanism and the disclosure shown to those users." A vendor who cannot answer this cleanly is a vendor your compliance team will eventually have to explain.

Acceptable use. "Provide your current acceptable use policy and confirm our stated use case is permitted under it." Get this before signature rather than after a suspension. Our guide to proxy acceptable use policies covers what is typically forbidden.

Logging and retention. "State what connection metadata is retained, for how long, in which jurisdictions it is stored, and under what process it is disclosed."

KYC and approval. "Describe your onboarding checks and any use-case approval step, including typical elapsed time." Some vendors will take a week to approve an account, which matters if you are switching under pressure. Our notes on why providers require KYC explain the driver.

Corporate facts. Legal entity, jurisdiction of incorporation, years operating, and whether the network is owned or resold. Ask directly. The answer to "do you operate this network or resell it" is a fact, and evasiveness is itself the result.

Support hours and channels, with the actual first-response time by severity, not an aspiration.

Escalation path for a block. "Describe what happens when we report that a specific target has begun rejecting your addresses. Who acts, on what timeline, and what remedies exist?" This is the single most common operational problem in this category and most contracts are silent on it.

Replacement policy. For static addresses, "what is the process and cost to replace a flagged address, and is there a monthly allowance?"

Incident communication. "Where are incidents published, and what is your notification commitment?" Ask for a link to the status page and look at its history.

Remedy, not uptime theatre. Every vendor prints a high uptime number. Ask instead: "state the remedy when the commitment is missed, the process to claim it, and the cap." A credit you have to ask for in writing within five business days is a different product from an automatic one. Our guide on reading a proxy provider SLA covers the clauses that matter.

Exit terms. Notice period, whether static addresses can be retained or ported, what happens to unused credits or prepaid terms, and how quickly credentials are revoked. Write the exit before the entrance. Our guide to switching proxy providers without downtime covers the mechanics.

State the trial in the RFP, not after shortlisting, so vendors know what they are being measured on.

Duration and volume. "Seven days, up to N requests, against our own targets."

Targets. Yours, not theirs. A demo dashboard proves that a demo dashboard works.

The metrics you will record. Success rate by target class, median and 95th percentile latency, bytes per successful record, and the count of distinct exit addresses observed.

The pass threshold. Put a number on it. "A success rate at or above X% on target class A over 50,000 requests, with no single hour below Y%." Vendors who know the threshold will tell you honestly whether they can meet it, which saves a trial.

Who runs it. Your harness, your code, on your infrastructure. A vendor-run trial measures the vendor's harness.

What happens to the data. State that trial traffic and results are yours and will not be shared.

Be explicit that you will run the same trial against every shortlisted vendor with the same code and the same targets in the same week. Load conditions on a target vary week to week, and a trial run in March against one vendor is not comparable with one run in May against another. Our comparison of proxy free trials and refund policies covers what vendors typically offer.

Put the weights in the document. It costs you nothing and it changes the quality of every response you receive, because vendors stop guessing what you care about.

Adjust the weights to your situation, but keep the trial and the normalised price together above half the total. Those are the two things you can verify. Everything else is a document.

One rule worth stating in the RFP: an unanswered question scores zero rather than triggering a follow-up. Otherwise the vendor with the best sales engineer wins the clarification round rather than the vendor with the best answer.

• Answer in our numbering. Same section and question numbers, same order.
• One file, and a separate machine-readable price sheet. A CSV or spreadsheet with your line items, so nobody retypes numbers.
• Prices in USD per month, excluding tax, with the term stated. Convert your own currency if you must, and say the rate used.
• No marketing collateral in the response body. Attach it separately if you like; it is not scored.
• Name the responder. A person, an email, a phone number, and who has signing authority.
• Deadline, and what late means. Say whether late bids are read at all.
• A single clarification window. All questions by one date, all answers published to all bidders together. This one rule prevents the most common procurement failure in small teams, where one chatty vendor gets a better brief than the others.

Cutting these makes the document shorter and the answers better.

"How many IPs do you have?" Unverifiable and uncorrelated with whether your targets accept them. Ask about ASNs and prefixes instead.

"What is your success rate?" Against which targets, measured by whom? Every vendor prints a high number. You will measure your own in the trial, which is the only figure that means anything.

"Are your proxies undetectable?" No product is, and the question invites the least honest vendor to give the most confident answer.

"Do you support [long list of tools]?" Anything that speaks HTTP or SOCKS5 works. Ask for hostnames and ports instead and you have answered the whole list.

"Please describe your infrastructure." You will get a page of prose. Ask the three specific questions you actually care about.

Anything you will not enforce. Do not ask for a 99.99% commitment you will never claim against, or a security certification you will not check. Every unenforced requirement is a place where a vendor learns your document is decorative.

Finally, resist the temptation to send this to a dozen vendors. Four is plenty: two incumbents or obvious fits, one cheaper challenger, one you would not otherwise have considered. Our guide to spotting a fake proxy provider before you buy covers how to filter the long list before you send anything.