SLA Clauses That Matter in an Enterprise Scraping Contract

Most enterprise scraping contracts guarantee one thing well: invoice amount. Everything else — success rate, retry behavior, geographic coverage, what happens when an IP range gets blacklisted mid-run — tends to live in a one-page SLA appendix written to be unenforceable. By the time a data team notices, the pipeline has been degrading for a quarter and the credits available are capped at a fraction of one monthly invoice.

The vendor-selection stage is where to fix this. Discovery questions matter earlier in the funnel; a companion piece on vendor questions before signing covers that ground. This one is about the redline: which clauses in an enterprise scraping SLA deserve a real fight, and which are theatre that costs nothing to concede.

Define Success Rate Before Anyone Signs

A "95% success rate" in a proxy or extraction contract means nothing without three subordinate definitions: what counts as a request, what counts as a success, and over what denominator the ratio is calculated. Vendors differ sharply here, and the difference is the entire SLA.

The honest baseline is wide. Independent benchmarks of web scraping APIs in 2026 showed success rates spanning 33.3% to 95.8%, with the middle of the field between 65% and 80%. On protected targets specifically, datacenter success rates fall to 40–60%, while residential pools stay in the 90–99% range. A single SLA number that averages across both target classes hides that gap.

Push for three contractual definitions in writing:

• Success event: HTTP 2xx response containing the specified fields, parsed and schema-validated, not merely returned. A 200 with an empty body or a soft-block page is not a success.
• Request universe: successful requests divided by total billable requests, measured per target domain class (public, light-protection, hard-protection) rather than account-wide.
• Measurement window: rolling 30-day, calculated monthly, with the raw log exportable on demand. Quarterly windows let a bad month hide inside a good one.

Retries Are Not Free, and Should Not Be Billed as Successes

The second clause worth a redline is retry accounting. Some vendors bill every attempt, charge for the retry, then count the eventual 200 toward the success rate. The customer pays three times for one record and sees a healthy dashboard.

Three terms close this hole:

• Retries triggered by vendor-side failures (proxy ban, upstream timeout, CAPTCHA on a path the vendor is supposed to solve) are not billable.
• Retries are counted as one request in the success-rate denominator, not N.
• A per-URL cap on retries, with a hard timeout, prevents a stuck job from quietly accumulating six-figure bills over a weekend.

Make the vendor expose retry telemetry at the request-ID level. Without it, no audit of the SLA is possible, and the number on the invoice is the only truth.

Geographic Coverage Needs Named Regions, Not a Globe Emoji

"Global proxy coverage" on a marketing page typically means the vendor has IPs in most countries. It does not mean they have enough IPs in Germany to run a 2 M-request DACH e-commerce job without the pool recycling, and it does not mean their Brazilian residential coverage is anything beyond São Paulo and Rio.

Geo-coverage guarantees belong in the SLA as a matrix: minimum IPs available per named country, minimum ASN diversity, and a response-time target per region. For regulated workflows (financial data, pricing, healthcare), add a residency clause stating which jurisdictions requests may egress from. This matters more than vendors admit, especially when the end buyer is in the EU and the extraction endpoint sits in a non-adequate country.

Ban-Rate Credits That Actually Pay

Standard SaaS SLAs typically offer 99.9% uptime with service credits capped at one month's fees. For a scraping pipeline feeding a trading model or a competitive-pricing engine, that cap is a rounding error against the real cost of a dark feed. Gartner's often-quoted figure puts average downtime at about $5,600 per minute, with e-commerce peaks exceeding $12,000 per minute.

Worse, only about 12% of customers actually file SLA credit claims, so vendors retain most of what they committed to on paper. A credit regime worth negotiating has four properties:

• Auto-credit: the vendor applies the credit on the next invoice when their own telemetry shows a miss. No claim form.
• Tiered thresholds: below 95% success triggers 10% credit, below 90% triggers 25%, below 80% triggers 50% and a right to terminate without penalty.
• Credit cap above one invoice. Push for three months of fees as the ceiling, not one. Vendors resist; it is still worth asking.
• Credits apply to the broken job, not aggregate account spend. A degraded German proxy pool should not be offset by a healthy US pool on the same contract.

1. 11Vendor telemetry detects success rate miss against tier · Vendor
2. 22Miss is logged against the specific job, not the account · Vendor
3. 33Tier threshold maps to credit percentage (10/25/50) · Contract
4. 44Credit applied automatically on next invoice · Vendor
5. 55Raw log exported to customer for independent audit · Customer
6. 66Below 80% triggers termination right without penalty · Customer

Uptime Clauses Need the Decimal Places

Uptime targets look identical on a slide and behave very differently in production. At 99.9% uptime, a service permits roughly 8.76 hours of downtime per year; 99.99% permits about 52.6 minutes; 99.999% permits only about 5.26 minutes. For a scraping stack feeding a nightly batch, 99.9% is probably fine. For a system backing real-time price monitoring, it is a weekly outage budget.

Separate "API uptime" from "extraction success". Many vendors meet the first while silently failing the second: the control plane answers, the proxies route, and the responses are soft-blocked HTML. The SLA should name both as independent commitments with independent credits.

BYOK Pass-Through Terms

Scraping pipelines increasingly feed an LLM step: parsing, extraction, summarization, classification. When the vendor runs that step on their own API key, three things happen: the customer pays a markup, the token-level cost math gets opaque, and prompt and response payloads end up in a third party's logs. A bring-your-own-key arrangement solves all three, but only if the contract is written for it.

The clauses that matter:

• The customer's provider keys are used exclusively for the customer's workloads and never pooled.
• Keys are stored encrypted at rest, with an explicit deletion SLA on contract termination (30 days is standard, 7 is better).
• The vendor passes through model selection without opinion. Routing choices between providers belong to the customer, not the vendor's default. The economics of this are covered in a prior piece on multi-provider LLM routing.
• Token-level usage logs, exportable, keyed to the originating request.

BYOK is also where regulated buyers get leverage on data residency: if the extraction vendor never holds the model key, the surface area for a GDPR upper-tier fine of €20 million or 4% of global turnover shrinks.

Data Retention and Deletion

Retention clauses are where scraping contracts most often fail audit. The default in many vendor DPAs is a 90-day post-termination retention window; one commonly used template keeps customer data in a limited-function account for 90 days after termination before deletion. For some buyers that is acceptable. For a healthcare or financial-services buyer whose scraped corpus may inherit personal data from a target site, it is not.

The reason this matters is downstream exposure. In November 2022, Meta was fined €265 million by the Irish supervisory authority after attackers scraped user data through Facebook's Contact Importer. The buyer is not Meta in that scenario; the buyer is the firm that bought a dataset downstream and did not ask where it came from. Retention clauses need:

• A named retention window per data class (request logs, response payloads, extracted records, derived embeddings).
• A deletion-on-request path with a verification artifact, not just an email reply.
• Subprocessor list and change-notice period of at least 30 days.
• Breach notification within 72 hours, aligned to GDPR Article 33.

Data Quality Floors Are Separate From Success Rate

A 200 response with the right schema can still contain nonsense: stale prices, truncated descriptions, duplicate rows, fields that silently moved from one DOM path to another after a site redesign. Gartner research cited across the data industry puts the average cost of poor data quality at roughly $12.9 million per organization per year. That cost is inherited the moment scraped data lands in a warehouse.

A quality floor belongs in the SLA as a separate commitment: a named completeness threshold per field, a freshness window, and a schema-drift notification path. Vendors who refuse to commit here are telling the buyer that quality is a best-effort property of their service, which is worth knowing before signing.

What Is Vendor Theatre

Not every clause rewards a redline. The ones that typically do not move the needle:

• "Enterprise-grade security" without a SOC 2 Type II report attached. Ask for the report, skip the adjective.
• Named Slack-channel support without a response-time SLA. The channel is not the commitment.
• "Unlimited retries" as a feature. This is cost transfer, not reliability.
• Volume commitments phrased as a floor the vendor meets. The ceiling and the per-domain mix are what break.

Where This Leaves the Buyer

The pattern across these clauses is the same: force the vendor to define the measurement, expose the telemetry, and tie remedies to the specific thing that broke. Success rate without a definition, uptime without a decimal, credits without an auto-apply mechanism, BYOK without key-handling terms, retention without a deletion artifact — each of these is a line item that reads strong and enforces weak.

Teams running serious extraction pipelines usually arrive at this document the hard way, after one quiet quarter of degraded data and a credit claim capped at a fraction of the damage. The faster path is to walk into the final vendor conversation with the redline already written. For a scoping call on how a pipeline-first stack handles these clauses in practice, reach the Search.co team, or review the architectural starting points in the platform overview.