Settings

A setting is a request field with a default that changes how a product works: how long a scrape may take, which browser renders the page, how long a sandbox lives, how a routine retries. Each product has a page that lists its settings, each with its default, the values it takes, what it changes and an example, and ends with the behaviour that is fixed in the beta.

Every default and range on these pages is read from the API spec, the file the API reference and the SDKs are built from. The docs build fails when a page and the spec disagree, or when the spec gains a setting no page lists.

Where you set them

Per request, in the body of the call, or on the object a setting belongs to: a routine definition's defaults, a sandbox, a browser session. The SDKs take the same field names in the request body. Some CLI examples use older flag names, which CLI 0.1.3 still takes. CLI 0.1.3 names a flag after its field in kebab case (timeout_s is --timeout-s), except: on_idle is --on-timeout, crawl's allow_subdomains is --include-subdomains, and a list is a repeated singular flag on scrape (--format markdown --format links, --header), a repeated plural one on crawl (--include-paths), and one comma-separated value elsewhere (video --formats mp4,gif, sandbox create --api-scope, keys create --scope).

Project and organization defaults, so you stop repeating a setting in every call, are planned and not built. Until they ship, leave a field out to get the default these pages show.

Out of range

A value outside a setting's values fails the request with 400 invalid_request, and its errors list points at the field. A value the spec allows but your plan does not, such as a sandbox timeout_s over an hour, fails with 422 limit_exceeded, and its limit member names the limit. Limits lists every limit, and GET /v1/limits shows yours.

Vault

Vault has no settings: a connection's fields are its own data (the pack, the hosts it may reach, the secret). See Vault.