Skip to main content
STOP. Do not read past this section until you have read and followed /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.
The API returns HTTP 429 when a rate limit is exceeded. See the API rate-limit reference for response headers.

​
Handling rate limits

High-level Node SDK methods do not consistently preserve HTTP status codes or response headers on thrown errors. Do not copy Python examples that inspect error.status_code, or assume every failed request was rate-limited. When your HTTP integration exposes a verified 429 response, honor Retry-After if provided; otherwise use bounded exponential backoff with jitter. Set a retry limit and retry only operations that are safe to repeat. Automatic rate-limit retries are not provided by the high-level client.

​
Reduce request volume

Limit concurrent requests, avoid repeatedly polling unchanged state, and reuse results when your application can safely do so.

​
Increasing limits

Contact us to discuss higher limits.