Recover a failed extraction

Read both the HTTP status and the operation state. An extraction can return HTTP 200 with a failed operation.

Symptom or code	Next step
authentication_required	Check account and access; keep credentials out of logs.
402 subscription_required	Paid Zilch access is required. Check the subscription on the signed-in account; sign-in alone does not grant access.
javascript_unavailable	Use static HTML extraction; do not request JavaScript execution.
robots_disallowed	Respect the source site's extraction restriction.
not_public	Use a public HTTP or HTTPS page, not a private network address.
too_large or timeout	Try a smaller public page. Preserve the failed operation details.
idempotency_conflict	Restore the original body for the retained request key.
zilch_unavailable	Check service availability and retry later with the same entitled account. A service outage does not remove the paid-access requirement.

If acceptance is uncertain, inspect the existing operation before submitting another. Do not work around a robots or access restriction. Check the output reference for result fields and the shared help checklist for details to retain.

Preserve work before correction

1. Keep the original URL and options, exact operation ID if one was received, and non-secret error. For an API submission retain the original body and request key privately, without the Bearer token.
2. In the workbench, use Check selected request to read the same operation. If no ID arrived but the submission remains, use Check existing submission.
3. Correct the specific condition: identity for authentication, active paid Zilch access for subscription refusal, or a suitable public static source for page limitations. Do not conflate these fixes.
4. Inspect the existing state after recovery. A saved failed operation remains evidence of that attempt; starting another extraction is a deliberate new action, not proof the old one succeeded.

If the response remains unreadable or the source is wrong, stop and send support the sanitized code, operation identity, intended source and steps already tried. Do not attach a full authenticated request or private page contents.

Prepare a support report

Use this checklist after preserving the original operation. It is a document example, not a captured support request or service payload. Fill it only with non-secret facts from the failure you observed.

# Support report

- Product and installed version:
- Exact action:
- Expected result:
- Observed result and non-secret error:
- Relevant operation/run ID, if safe to share:
- Steps already tried:
- Work preserved before retrying:

Check the report before sending: the exact symptom and preserved work should be clear, while credentials, raw authenticated requests and private page content should be absent.