Access refused or extraction failed
Start with the refusal you actually received. Signing in again is useful for missing authentication; it is not a universal fix for a subscription refusal or a source-page failure.
Preserve the evidence
Keep the original URL, options, operation ID if available, and non-secret error code. Keep the original body and request key for API recovery, but never include tokens or cookies in support notes.
| Visible symptom | Smallest useful check | Correction |
|---|---|---|
401 authentication_required | Is this the intended account or credential? | Restore authentication for that account. Do not infer paid access from sign-in. |
402 subscription_required | Does that account hold active paid Zilch access? | Review the account's Zilch subscription; do not switch endpoints or keys to bypass it. |
| A usage or pending limit | Is there already accepted work to inspect? | Inspect existing operations and wait for capacity; do not submit duplicates. |
HTTP success with failed | What does operation.error say? | Diagnose the saved error before deciding on new work. |
| Service unavailable or unreadable response | Was acceptance confirmed? | Keep the identity; retry the existing read after service recovery. |
Check the correction
For an access problem, refresh the account check in the workbench without submitting a paid extraction just to test it. For an already-recorded operation, inspect the same ID and state. An access correction does not retroactively turn a failed operation into a completed document.
Use source-boundary recovery for robots, private-network and script-only pages. If the outcome is still uncertain, follow safe retry recovery, then provide sanitized evidence to support.