# 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](/docs/zilch/robots-private-urls-and-javascript-pages) for robots, private-network and script-only pages. If the outcome is still uncertain, follow [safe retry recovery](/docs/zilch/retry-without-duplicating-work), then provide sanitized evidence to [support](/docs/shared/support).