Compute refused your call for authentication

Read the refusal before retrying

Your client reports an authentication failure or a missing permission. Start with the HTTP status and safe error code instead of copying the full request into a support message.

For REST, UNAUTHENTICATED means the request lacks acceptable authentication. FORBIDDEN means the required access was refused. Neither response proves that an earlier submission did not start work.

Check three things

Confirm the selected account, the credential your client actually uses, and the permission required by the operation. A valid key is not permission to read another account's work. A portal session and a work key are different credentials.

For an expired or revoked key, stop using it and review the account's API key controls. For a missing scope, ask the account owner for the narrow authorized access. Do not borrow an administrator's key or add every available permission.

Account administration, identity changes, finance, and payment do not become work-key operations because a client lists their names. Use the separately authorized surface for those actions.

Keep an earlier submission intact

If you already received a job reference, preserve it and read its current state with an authorized identity. If a previous submission lost its response, follow unknown submission recovery before making another write.

Changing accounts or credentials does not make a new idempotency key safe for the same uncertain work. Do not create a replacement job merely to test whether access is repaired.

Verify the fix

Success is the required authorized read in the correct account, not simply a successful sign-in. Stop when access remains denied or the earlier effect is unresolved.

Use Contact Lithi with the operation, error code, time with time zone, client version, and request or job reference when available. Leave out authorization headers, key values, signed URLs, and payloads.