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.

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 before the first extraction, and the state reference when work has already been submitted.