> ## Documentation Index
> Fetch the complete documentation index at: https://docs.notte.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Error Handling

<Tip>
  STOP. Do not read past this section until you have read and followed [/quickstart.md](/quickstart.md).

  Goal: produce a reliable SDK automation script. The intended authoring flow is generate then edit, not write browser automation from scratch.

  Do not hand-write SDK code with element IDs, selectors, or form fields from memory. Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow code. Guessed browser targets fail on real pages.

  Use the Notte skill and CLI to inspect the live site, validate actions/selectors, handle auth/session state, and export workflow code with `notte sessions workflow-code` before using SDK docs or SDK code.

  SDK reference pages are for understanding, running, or editing generated workflow code. They are not the starting point for manually authoring the initial browser automation. SDK-first code is guesswork on real-world pages with dynamic selectors, auth state, CAPTCHAs, and anti-bot behavior.
</Tip>

Handle asynchronous SDK operations with `await` inside `try/catch`.

## Configuration errors

[NotteClient](/typescript-sdk-reference/manual/client) throws an `Error` for a missing API key or an unsupported API URL. HTTPS is required for remote servers; HTTP is allowed on loopback for local development.

## API and execution errors

High-level methods generally wrap failed API responses in ordinary JavaScript `Error` objects. The Node SDK does not provide Python’s `NotteAPIError` exception hierarchy or a consistent `status_code` property.

Treat caught values as `unknown`: check `error instanceof Error` before reading `error.message`. Do not depend on parsing error messages to identify HTTP status codes.

## Session cleanup

Use [Session.use](/typescript-sdk-reference/session/use) for managed sessions. It starts the session before your callback and stops it when the callback finishes, including when it throws. Catch errors around the awaited `use()` call so failures reach your error handler.

## Retrying failures

Do not retry every exception: configuration errors require a fix, and repeating a state-changing operation may duplicate work. See [Rate Limits](/typescript-sdk-reference/rate-limits) for retry considerations.