Reliability Contract

The Six Clauses

1. Recoverable failures are the platform's job. Mode and tier choice, applying the platform's own hints, per-domain pacing, queueing of overflow, retries on timeouts and search-engine failover happen automatically, on by default, at the lowest tier that works.
2. Only unreachable targets fail. 404 and 410 responses, an origin that is down, a login or paywall, and legally excluded targets fail. Each failure returns a stable machine-readable reason, a retryable flag and retry_after_seconds.
3. A block page is never a success. A challenge, interstitial or block page is returned as a failure with its protection class, never as a successful scrape.
4. A failed request is not charged. Credits held for a request that fails are refunded automatically.
5. Circuit breakers separate strategy from site. Breakers distinguish failures caused by the request strategy from failures caused by the site, try a different strategy before tripping, and report when the domain becomes available again.
6. Recovery is measured and published. The platform measures the share of requests that succeed after in-platform recovery per domain and publishes it as recovered_success_rate in the public domain stats. SDKs return the same contract and never turn a success into a failure.

Failure Fields

Every failed scrape carries a next_action object with a stable reason_class, a boolean retryable and retry_after_s (seconds, or null when no wait applies). retryable is true only when retrying, waiting or a higher tier can resolve the failure without changing the request, target or account.

{
  "next_action": {
    "type": "retry_with_tier",
    "reason_class": "datadome",
    "retryable": true,
    "retry_after_s": null,
    "retry_with": { "tier": "4", "mode": "js" }
  }
}

How It Is Measured

The live reliability feed reports success, latency and cost by anti-bot class and tier. Per domain, /api/v1/domains/{domain}/public-stats reports success_rate and recovered_success_rate, aggregated over 30 days.