# Sign-in, API keys and entitlement

Zilch separates who is making a request from whether that account may start paid extraction. This distinction explains why a valid credential can still receive an access refusal.

## Three independent checks

| Check | What it establishes | What it does not establish |
| --- | --- | --- |
| Sign-in or an account API key | The requesting account's identity | An active paid Zilch entitlement |
| Active paid Zilch entitlement | Product access for that account | Unlimited service capacity or successful extraction |
| Allowance and request capacity | Whether additional work can be admitted | Authentication, payment, or source-site permission |

The workbench uses its signed-in account. An API integration uses a Bearer credential for its account. Neither a credential's existence nor a key-management screen is proof of product access. Do not create or revoke keys just to diagnose a subscription refusal: shared account keys may also be used by other tools.

## Read access separately from work state

The following is reference text, not commands or a captured API response.

```text
401 authentication_required: authentication is missing.
402 subscription_required: required paid Zilch access is missing.
reserved: inspect the existing operation.
completed: inspect the result, warnings and truncation.
failed: inspect the saved error before retrying.
cancelled: no completed result is available.
```

A completed access check and a completed extraction are different outcomes. Even an authenticated, entitled request can fail because the source refuses access, the page cannot be fetched, or a service limit is reached. Inspect the saved operation rather than treating all failures as a sign-in problem.

Use [Confirm paid Zilch access](/docs/zilch/confirm-paid-zilch-access) before the first extraction, and the [state reference](/docs/zilch/extraction-reference) when work has already been submitted.