SE Home
Help
  • Documentation
  • Help centre
SEScrape Engine

Getting started

DocumentationQuickstartAuthenticationPlayground

Extracting data

Selecting valuesTransformsLists & tablesPage dataAI extractionMCP server

Fetching pages

Custom requestsTimeouts & redirectsCachingAutomatic retriesFallback strategies

Browsers & actions

BrowsersActionsRecipesScreenshots & PDFStored files

Getting past blocks

Anti-bot protectionCaptchasProxiesFingerprintsSessions

Workflows

Multi-step requestsVariablesPaginationBatchCrawlingTemplatesSchedules & monitoringAsync jobs & webhooksExport to S3, Sheets, databases & webhooks

Account & billing

CreditsSecretsPlansLimitsLogs & request idsNotificationsAccountAffiliate programmeHelp centre

Reference

POST /scrapeGET /sessions/:idGET /browsersGET /proxies/countriesGET /healthErrors
Documentation

Getting started

DocumentationQuickstartAuthenticationPlayground

Extracting data

Selecting valuesTransformsLists & tablesPage dataAI extractionMCP server

Fetching pages

Custom requestsTimeouts & redirectsCachingAutomatic retriesFallback strategies

Browsers & actions

BrowsersActionsRecipesScreenshots & PDFStored files

Getting past blocks

Anti-bot protectionCaptchasProxiesFingerprintsSessions

Workflows

Multi-step requestsVariablesPaginationBatchCrawlingTemplatesSchedules & monitoringAsync jobs & webhooksExport to S3, Sheets, databases & webhooks

Account & billing

CreditsSecretsPlansLimitsLogs & request idsNotificationsAccountAffiliate programmeHelp centre

Reference

POST /scrapeGET /sessions/:idGET /browsersGET /proxies/countriesGET /healthErrors

Automatic retries

Websites fail now and then: a server under load answers 503, a rate limiter answers 429, a connection drops. Ask the API to retry, and these transient failures are absorbed before they reach you.

{
  "target_url": "https://example.com",
  "fields": ["h1"],
  "options": { "retry": 3 }
}

retry is the number of extra attempts after the first one, from 0 (the default) to 5.

See it work

The two requests below target a demo page that answers 503 Service Unavailable twice before it succeeds.

Without retry, the first 503 is final and the API returns an error:

Actions

Data

With "retry": 3, the API tries again until the page answers (usually on the third attempt), and you get the data. meta.attempts tells you how many requests it took:

Actions

Data

{ "status": 200, "data": ["It worked"], "meta": { "attempts": 3, … } }

What is retried

FailureRetried
Network error (connection refused or reset, DNS, TLS)yes
Timeoutyes
429 Too Many Requestsyes
5xx server errorsyes
Other 4xx (404, 403…)no, retrying won't change the answer. Choose your own list if a site needs it
Invalid URL, selector or bodyno

Exponential backoff

The API waits longer after each failure, so a struggling site gets time to recover. By default the first wait is about 0.5 s and each following one doubles, up to 8 s, with some randomness so many clients don't retry at the same instant:

Before attemptWait (default)
20.25–0.5 s
30.5–1 s
41–2 s
52–4 s
64–8 s

If the site sends a Retry-After header, the API waits that long instead, up to the maximum delay.

Tune it with options.backoff:

"options": {
  "retry": 4,
  "backoff": {
    "initial_delay": 1000,
    "max_delay": 10000,
    "multiplier": 3,
    "jitter": false
  }
}
PropertyTypeDefaultDescription
initial_delayinteger (ms)500Wait before the first retry, 0 to 30000
max_delayinteger (ms)8000Longest wait, Retry-After included, 0 to 30000
multipliernumber2Each wait is the previous one times this, 1 to 10. 1 waits the same every time
jitterbooleantrueWait a random time between half and all of the computed delay

With the example above, the waits are 1 s, 3 s, 9 s, then 10 s.

Each attempt has its own timeout, so a request with retries can take longer to answer.

Choose which statuses to retry

By default the API retries 429 and every 5xx. Set options.retry_on to your own list of status codes, from 400 to 599. It replaces the default list:

"options": { "retry": 3, "retry_on": [403, 429, 503] }

Network errors and timeouts are always retried.

Retrying the same request isn't enough?

If a site refuses the request itself (a bot User-Agent, a missing cookie), use a fallback strategy to ask differently.

When every attempt fails

You get the error from the last attempt, with attempts set to the number of requests made:

{
  "target_url": "https://example.com",
  "error": {
    "code": "HTTP_ERROR",
    "message": "HTTP 503 for https://example.com",
    "status": 503,
    "attempts": 4,
    "strategy": 0
  }
}

On this page

  • See it work
  • What is retried
  • Exponential backoff
  • Choose which statuses to retry
  • When every attempt fails